Bug#843018: ITP: node-braces -- Fast, comprehensive, bash-like brace expansion implemented in JavaScript

[Sruthi Chandran]

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

* Package name: node-braces
  Version : 2.0.2
  Upstream Author : Jon Schlinkert (https://github.com/jonschlinkert)
* URL : https://github.com/jonschlinkert/braces
* License : Expat
  Programming Lang: JavaScript
  Description : Fast, comprehensive, bash-like brace expansion
implemented in JavaScript. Complete support for the Bash 4.3 braces
specification, without sacrificing speed.

Bug#843019: ITP: node-expand-brackets -- Expand POSIX bracket expressions (character classes) in glob patterns

[Sruthi Chandran]

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

* Package name: node-expand-brackets
  Version : 2.1.3
  Upstream Author : Jon Schlinkert (https://github.com/jonschlinkert)
* URL : https://github.com/jonschlinkert/expand-brackets
* License : Expat
  Programming Lang: JavaScript
  Description : Expand POSIX bracket expressions (character classes)
in glob patterns

Bug#843021: RFP: yarn -- a fast, reliable, and secure package manager for Node.js

[Paolo Greppi]

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

--- Please fill out the fields below. ---

   Package name: yarn
Version: 0.16.1
Upstream Author: Yarn Developers 
URL: https://github.com/yarnpkg/yarn
License: BSD-2-Clause
Description: Fast, reliable, and secure alternative for the npm
client, compatible with the npm registry.
.
Fast: Yarn caches every package it downloads so it never needs to again.
It also parallelizes operations to maximize resource utilization so
install times are faster than ever.
.
Reliable: Using a detailed, but concise, lockfile format, and a
deterministic algorithm for installs, Yarn is able to guarantee that an
install that worked on one system will work exactly the same way on any
other system.
.
Secure: Yarn uses checksums to verify the integrity of every installed
package before its code is executed.



signature.asc
Description: OpenPGP digital signature

Re: Bug#843021: RFP: yarn -- a fast, reliable, and secure package manager for Node.js

[Lars Wirzenius]

On Thu, Nov 03, 2016 at 08:36:21AM +0100, Paolo Greppi wrote:
>Package name: yarn
> URL: https://github.com/yarnpkg/yarn

My cmdtest package provides yarn, since the main tool it now provides
is yarn (a testing tool), not cmdtest. Perhaps your package could be
called yarnpkg?

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Re: C:O:.N:.G:.R:.A:.T:.S:reysancho21 wPQf

[REY SANCHO]

How do i get it

On Sep 24, 2016 12:05 PM, "Helmut Grohne"  wrote:

> dfgh C0NGRATUIATl0N:reysancho21
>
> _WaImart_sent_y0u_glft_card_worth_(1000:D0IIars)
>
> __confirm_immediately__
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> [t 0 u n 5 u b U ]
> [t 0 0 p t t 0 0 u t ]  
> 
>
>

Re: OpenSSL 1.1.0

[Tino Mettler]

On Wed, Nov 02, 2016 at 14:02:52 -0300, Lisandro Damián Nicanor Pérez Meyer 
wrote:

[...]

> Today we the Qt/KDE team were hit but this same thing in the middle of our 
> transition: libpq-dev pulls in libssl-dev which makes Qt5 FTBFS.

Hi,

libqt staying at OpenSSL 1.0 means all binaries linking against libqt
need to stay at OpenSSL 1.0. Is this correct?

Regards,
Tino

Bug#843043: ITP: pd-py -- Python scripting objects for Pure Data

[IOhannes m zmoelnig]

Package: wnpp
Severity: wishlist
Owner: IOhannes m zmoelnig 

* Package name: pd-py
  Version : 0.2.0
  Upstream Author : Thomas Grill 
* URL : http://g.org/research/software/py/
* License : GPL2+
  Programming Lang: C++/Python/Pd
  Description : Python scripting objects for Pure Data

 This object library provides full integration of the Python scripting language
 into the Pure Data (Pd) and Max/MSP real-time systems.
 .
  - py loads Python modules and allows to execute functions therein.
  - pyext uses Python classes to represent full-featured message objects.
 .
 Multithreading (‘detaching’) is supported for background operation.

I intend to maintain the package under the pkg-multimedia-maintainers umbrella
as part of the pd-externals packaging effort.

Bug#843044: ITP: pd-vasp -- VASP modular - Vector assembling signal processor for PD

[IOhannes m zmoelnig]

Package: wnpp
Severity: wishlist
Owner: IOhannes m zmoelnig 

* Package name: pd-vasp
  Version : 0.1.3
  Upstream Author : Thomas Grill 
* URL : https://github.com/g/vasp
* License : GPL-2+
  Programming Lang: C++/Pd
  Description : VASP modular - Vector assembling signal processor for PD

 VASP is a package for PD or Max/MSP consisting of a number of externals
 extending these systems with functions for non-realtime array-based audio data
 processing. VASP is capable of working in the background, therefore not
 influencing eventual dsp signal processing.

I intend to maintain the package under the pkg-multimedia-maintainers umbrella
as part of the pd-externals packaging effort.

Bug#843047: ITP: pd-pool -- Hierarchical data storage for Pure Data

[IOhannes m zmoelnig]

Package: wnpp
Severity: wishlist
Owner: IOhannes m zmoelnig 

* Package name: pd-pool
  Version : 0.2.1
  Upstream Author : Thomas Grill 
* URL : http://g.org/research/software/pool
* License : GPL-2+
  Programming Lang: C++/Pd
  Description : Hierarchical data storage for Pure Data

 Pool can store and retrieve key/value pairs, where a key can be any atom and
 the value can be any list of atoms. Pool can manage folders, a folder name can
 be any atom. Pool objects can be named and then share their data space.
 Clipboard operations are possible in a pool or among several pools. File
 operations can load/save data from disk.

I intend to maintain the package under the pkg-multimedia-maintainers umbrella
as part of the pd-externals packaging effort.

Bug#843048: ITP: pd-xsample -- extended sample objects for Pure Data

[IOhannes m zmoelnig]

Package: wnpp
Severity: wishlist
Owner: IOhannes m zmoelnig 

* Package name: pd-xsample
  Version : 0.3.1
  Upstream Author : Thomas Grill 
* URL : http://g.org/research/software/xsample/
* License : GPL-2+
  Programming Lang: C++/Pd
  Description : extended sample objects for Pure Data

 This is a collection of efficient buffer-based sampling objects for Pure Data
 (Pd) and Max.
 There's the variable-speed interpolating player [xgroove~], the index-driven
 [xplay~] and the sample-accurate recorder [xrecord~]


I intend to maintain the package under the pkg-multimedia-maintainers umbrella
as part of the pd-externals packaging effort.

Re: Bug#843021: RFP: yarn -- a fast, reliable, and secure package manager for Node.js

[Paolo Greppi]

On 03/11/2016 09:10, Lars Wirzenius wrote:
> On Thu, Nov 03, 2016 at 08:36:21AM +0100, Paolo Greppi wrote:
>>Package name: yarn
>> URL: https://github.com/yarnpkg/yarn
> 
> My cmdtest package provides yarn, since the main tool it now provides
> is yarn (a testing tool), not cmdtest. Perhaps your package could be
> called yarnpkg?

cmdtest provides yarn since this commit:
http://git.liw.fi/cgi-bin/cgit/cgit.cgi/cmdtest/commit/?id=859bb5ba9631df883dd7b074ff649ea2ca76e1ad

A package search for yarn currently returns no match.
https://packages.debian.org/search?keywords=yarn

The real issue here is that both cmdtest and the proposed package
install a yarn binary.

The conflict could be addressed in several ways:

1. as you suggest, renaming this package and the binary it installs to
yarnpkg

2. keeping the package name yarn but renaming the binary to yarnpkg

3. renaming the executable yarn in cmdtest to yarn-something-else, and
have cmdtest provide yarn-something-else

4. ignoring the conflict and setting the Conflict flags in both packages
(https://www.debian.org/doc/debian-policy/ch-relationships.html#s-conflicts)

... but I am not sure if all are feasible.

This looks similar to what happened with nodejs / node.
To avoid a package naming conflict with the old package node
(https://packages.qa.debian.org/n/node.html), node entered Debian as nodejs.
To avoid a binary conflict, also the binary was renamed nodejs from node.
People who do not use the old node package and like to invoke node as
node rather than nodejs can install the node-legacy package.

Similar to node/nodejs, for 1 and 2 there could be a
yarn-legacy/yarnpkg-legacy package for those who do not use cmdtest and
like to invoke yarn as yarn rather than yarnpkg.
For 3, there could be a cmdtest-legacy package for those who do not use
yarn/yarnpkg and like to invoke the yarn binary in cmdtest as yarn
rather than yarn-something-else.

While technically flawless, in retrospect the way the nodejs conflict
was solved is not a success story in terms of expanding the Debian user
base (which is the main reason for having these trendy packages in).

At the moment we are confusing the newbies who come to Debian for
JavaScript development.
It would be easier if they could apt-get install node/yarn and then just
type node/yarn to use them.
For comparison, on macOS they can do brew install node/yarn and then
type node/yarn.

For node this may be possible sometime in the future as the old node
package is transitioning to ax25-node and the binary has also been
renamed /usr/sbin/ax25-node.

Finally, I looked at the popcon installed numbers - for what it's worth
and in relative terms.

- node (now ax25-node) peaked at ~1100

- cmdtest has ~50

- about 15% of those who install nodejs (~14000) also install
nodejs-legacy (~2000)

- npm (which is the main alternative to yarn as a nodejs package
manager) has ~6000

- for yarn/yarnpkg it's difficult to predict now, but probably it will
end up in the range 0-6000, high or low depending how much traction it
will get.

In conclusion, I leave it to those who know more what is the best thing
to do !




signature.asc
Description: OpenPGP digital signature

Bug#843054: ITP: node-yargs-parser -- mighty option parser used by yargs

[Sruthi Chandran]

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

* Package name: node-yargs-parser
  Version : 4.0.2
  Upstream Author : Ben Coe 
* URL : https://github.com/yargs/yargs-parser#readme
* License : ISC
  Programming Lang: JavaScript
  Description : the mighty option parser used by yargs

Re: OpenSSL 1.1.0

[Lisandro Damián Nicanor Pérez Meyer]

On jueves, 3 de noviembre de 2016 12:34:23 P. M. ART Tino Mettler wrote:
> On Wed, Nov 02, 2016 at 14:02:52 -0300, Lisandro Damián Nicanor Pérez Meyer
> wrote:
> 
> [...]
> 
> > Today we the Qt/KDE team were hit but this same thing in the middle of our
> > transition: libpq-dev pulls in libssl-dev which makes Qt5 FTBFS.
> 
> Hi,
> 
> libqt staying at OpenSSL 1.0 means all binaries linking against libqt
> need to stay at OpenSSL 1.0. Is this correct?

To the best of my knowledge yes, because Qt dllopens it and thus doesn't 
resolves symbols versions.

Note that this is valid for both Qt4 and Qt5.

-- 
UNIX is basically a simple operating system, but you have to be a
genius to understand the simplicity.
  Dennis Ritchie

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: Bug#843021: RFP: yarn -- a fast, reliable, and secure package manager for Node.js

[Jérémy Lal]

2016-11-03 13:32 GMT+01:00 Paolo Greppi :

> On 03/11/2016 09:10, Lars Wirzenius wrote:
> > On Thu, Nov 03, 2016 at 08:36:21AM +0100, Paolo Greppi wrote:
> >>Package name: yarn
> >> URL: https://github.com/yarnpkg/yarn
> >
> > My cmdtest package provides yarn, since the main tool it now provides
> > is yarn (a testing tool), not cmdtest. Perhaps your package could be
> > called yarnpkg?
>
> cmdtest provides yarn since this commit:
> http://git.liw.fi/cgi-bin/cgit/cgit.cgi/cmdtest/commit/?id=8
> 59bb5ba9631df883dd7b074ff649ea2ca76e1ad
>
> A package search for yarn currently returns no match.
> https://packages.debian.org/search?keywords=yarn
>
> The real issue here is that both cmdtest and the proposed package
> install a yarn binary.
>
> The conflict could be addressed in several ways:
>
> 1. as you suggest, renaming this package and the binary it installs to
> yarnpkg
>
> 2. keeping the package name yarn but renaming the binary to yarnpkg
>

If a rename happens, "yarnjs" should be something more natural for debian
users,
considering some other binaries are already renamed with that quite natural
"js" suffix.

3. renaming the executable yarn in cmdtest to yarn-something-else, and
> have cmdtest provide yarn-something-else


That makes the most sense here, considering what you said about the
popularity and the fact cmdtest has been providing "yarn" binary for such a
short time.

Maybe Lars can understand the amount of users it will affect should
be a parameter to decide which package has to rename its binary.


> 4. ignoring the conflict and setting the Conflict flags in both packages
> (https://www.debian.org/doc/debian-policy/ch-relationships.
> html#s-conflicts)
>

Conflicts is not meant to be used for that purpose, as the link you give
explains it
in details.

This looks similar to what happened with nodejs / node.
> To avoid a package naming conflict with the old package node
> (https://packages.qa.debian.org/n/node.html), node entered Debian as
> nodejs.
> To avoid a binary conflict, also the binary was renamed nodejs from node.
> People who do not use the old node package and like to invoke node as
> node rather than nodejs can install the node-legacy package.
>
> Similar to node/nodejs, for 1 and 2 there could be a
> yarn-legacy/yarnpkg-legacy package for those who do not use cmdtest and
> like to invoke yarn as yarn rather than yarnpkg.
> For 3, there could be a cmdtest-legacy package for those who do not use
> yarn/yarnpkg and like to invoke the yarn binary in cmdtest as yarn
> rather than yarn-something-else.
>
> While technically flawless, in retrospect the way the nodejs conflict
> was solved is not a success story in terms of expanding the Debian user
> base (which is the main reason for having these trendy packages in).
>
> At the moment we are confusing the newbies who come to Debian for
> JavaScript development.
> It would be easier if they could apt-get install node/yarn and then just
> type node/yarn to use them.
> For comparison, on macOS they can do brew install node/yarn and then
> type node/yarn.
>
> For node this may be possible sometime in the future as the old node
> package is transitioning to ax25-node and the binary has also been
> renamed /usr/sbin/ax25-node.
>

The TC resolution was to forbid the binary name "node" completely,
because it is too generic - hence the conflict is bound to happen again and
again.

Also note the nodejs-legacy package is confusing users a lot, it's not a
good
solution to jump into.

Jérémy

Re: Bug#843021: RFP: yarn -- a fast, reliable, and secure package manager for Node.js

[Ian Jackson]

Paolo Greppi writes ("Re: Bug#843021: RFP: yarn -- a fast, reliable, and secure 
package manager for Node.js"):
> On 03/11/2016 09:10, Lars Wirzenius wrote:
> > My cmdtest package provides yarn, since the main tool it now provides
> > is yarn (a testing tool), not cmdtest. Perhaps your package could be
> > called yarnpkg?
> 
> cmdtest provides yarn since this commit:
> http://git.liw.fi/cgi-bin/cgit/cgit.cgi/cmdtest/commit/?id=859bb5ba9631df883dd7b074ff649ea2ca76e1ad

You mean it "Provides: yarn" since then.  The actual binary was in the
package since 2013.

Another point of view is this:

I did a google search for `yarn program'.  It appears from that that
Yarn is actually something to do with Hadoop.  And also that people
might be interested in software tools relating to knitting.

I searched github for `yarn'.  There are lots of hits for other
programs, including:
  - a dialogue editor (for games, I think)
  - a VM
  - something to do with mongodb and .net
  - the Hadoop thing
  - a blogging application
  - a wrapper for ssh.
and lots more.

Obviously "yarn" is a really bad name.  Someone who picks a name like
that must obviously expect that they can't necessarily have that name
in every namespace.

There are two reasonable approaches in such a situation: "no one can
have it" (this is what Debian Policy says), and "first come first
served".

It is obviously disappointing that the Node.js community have made
this mistake again.  Or, it would be, if we didn't expect it of them.

Ian.

Re: Bug#843021: RFP: yarn -- a fast, reliable, and secure package manager for Node.js

[Lars Wirzenius]

On Thu, Nov 03, 2016 at 01:32:14PM +0100, Paolo Greppi wrote:
> cmdtest provides yarn since this commit:
> http://git.liw.fi/cgi-bin/cgit/cgit.cgi/cmdtest/commit/?id=859bb5ba9631df883dd7b074ff649ea2ca76e1ad

Yep, in 0.27-1, uploaded Sep 21 this year. cmdtest has included the
yarn program since June, 2013. I added that because people kept having
trouble finding the package when they want to install (my) yarn.

> A package search for yarn currently returns no match.
> https://packages.debian.org/search?keywords=yarn

I assume that's because it's a Provides, and not an actual package
name. I haven't created a separate yarn package to avoid making the
FTP masters from processing another package in NEW.

> The real issue here is that both cmdtest and the proposed package
> install a yarn binary.

I don't think that's the only reason, I think the package name
conflict is also an issue. But you're right that the binary name
conflict also needs be resolved.

> 1. as you suggest, renaming this package and the binary it installs to
> yarnpkg

Yes, please. :)

> 2. keeping the package name yarn but renaming the binary to yarnpkg

I don't see why you'd call the package yarn. There would be a conflict
with the yarn name that cmdtest provides.

> 3. renaming the executable yarn in cmdtest to yarn-something-else, and
> have cmdtest provide yarn-something-else

It's been called yarn in the cmdtest package for years. I'd prefer to
not rename it, thanks. It's a name that's dear to me, has some
pleasant memories associated with it, and that I've gotten used to.

The JS package manager called yarn is quite new. It wouldn't be
unreasonable to suggest to them to rename it to avoid a naming
conflict, in my opinion.

> 4. ignoring the conflict and setting the Conflict flags in both packages
> (https://www.debian.org/doc/debian-policy/ch-relationships.html#s-conflicts)

I don't think this is acceptable at all. There's no reason for these
two packages to conflict. There's no reason why we'd prevent someone
from installing both at the same time.

> For 3, there could be a cmdtest-legacy package for those who do not use
> yarn/yarnpkg and like to invoke the yarn binary in cmdtest as yarn
> rather than yarn-something-else.

Oh dear, please no. This is just insane. A whole bunch of work with no
actual benefit. It just makes things more complicated for everyone.

> At the moment we are confusing the newbies who come to Debian for
> JavaScript development.

I understand. I admit that I don't much care. Having to learn that
it's called yarnpkg in Debian, yarn on MacOS, and maybe something else
somewhere else seems not too big a deal to me. It's a very minor
difference compared to the churn in the Javascript ecosystem.

> It would be easier if they could apt-get install node/yarn and then just
> type node/yarn to use them.

Traditionally in Debian, we've handled naming conflicts by giving a
name to the first package using it. There have been exceptions of
course: node, and git come to mind. Some of these conflicts have been
solved by decree by the FTP masters, a couple by the technical
committee. Many have been resolved amicably by the Debian package
maintainers. Let's aim for that in this case.

I don't know of any cases when naming conflicts in Debian have been
solved by having a duel at Debconf. It's nearly a year to the next
Debconf, which is probably too long for solving this. Also, I've lost
my lightsabre.

We in Debian will always have naming conflicts like this, as long as
we have a flat namespace for packages (or in /usr/bin). It doesn't
help when upstreams don't do sufficient due diligence when choosing
names, meaning that we need to resolve them in Debian.

> - cmdtest has ~50

It's not a particularly popular package. I make no claim of
popularity, only of having used the name first.

> - for yarn/yarnpkg it's difficult to predict now, but probably it will
> end up in the range 0-6000, high or low depending how much traction it
> will get.

I don't think that is implausible. I'm not sure it's important, though.

> In conclusion, I leave it to those who know more what is the best thing
> to do !

Well, my opinion is still that it'd be nice if you called both the
package and binary yarnpkg. That would be a very simple, easy
solution. If you can convince upstream to also call the binary yarnpkg
(or yarnjs, or some other variant), that would be even better.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Re: Bug#843021: RFP: yarn -- a fast, reliable, and secure package manager for Node.js

[Lars Wirzenius]

On Thu, Nov 03, 2016 at 02:02:31PM +, Ian Jackson wrote:
> I searched github for `yarn'.

You don't find my software on github. I do not want to rely on
non-free services like github.

> There are lots of hits for other
> programs, including:
>   - a dialogue editor (for games, I think)
>   - a VM
>   - something to do with mongodb and .net
>   - the Hadoop thing
>   - a blogging application
>   - a wrapper for ssh.
> and lots more.

How many of those were public in mid-2013?

> Obviously "yarn" is a really bad name.  Someone who picks a name like
> that must obviously expect that they can't necessarily have that name
> in every namespace.

When I chose the name in 2013, I didn't other software that was called
yarn.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Bug#843059: ITP: node-extglob -- Extended glob support for JavaScript

[Sruthi Chandran]

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

* Package name: node-extglob
  Version : 1.0.0
  Upstream Author : Jon Schlinkert (https://github.com/jonschlinkert)
* URL : https://github.com/jonschlinkert/extglob
* License : Expat
  Programming Lang: JavaScript
  Description : Extended glob support for JavaScript. Adds (almost)
the expressive power of regular expressions to glob patterns.

Re: Bug#843021: RFP: yarn -- a fast, reliable, and secure package manager for Node.js

[Paolo Greppi]

On 03/11/2016 15:28, Lars Wirzenius wrote:
> The JS package manager called yarn is quite new. It wouldn't be
> unreasonable to suggest to them to rename it to avoid a naming
> conflict, in my opinion.

Fine, I have opened an "Issue" in the github tracker, let's see if this
is received constructively:
https://github.com/yarnpkg/yarn/issues/1656

> I don't know of any cases when naming conflicts in Debian have been
> solved by having a duel at Debconf. It's nearly a year to the next
> Debconf, which is probably too long for solving this. Also, I've lost
> my lightsabre.

Ahah I never had one anyway !




signature.asc
Description: OpenPGP digital signature

Re: Bug#843021: RFP: yarn -- a fast, reliable, and secure package manager for Node.js

[Lars Wirzenius]

On Thu, Nov 03, 2016 at 04:17:37PM +0100, Paolo Greppi wrote:
> Fine, I have opened an "Issue" in the github tracker, let's see if this
> is received constructively:
> https://github.com/yarnpkg/yarn/issues/1656

Thank you.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Bug#843066: ITP: node-array-union -- Create an array of unique values, in order, from the input arrays

[Sruthi Chandran]

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

* Package name: node-array-union
  Version : 1.0.2
  Upstream Author : Sindre Sorhus 
(sindresorhus.com)
* URL : https://github.com/sindresorhus/array-union#readme
* License : Expat
  Programming Lang: JavaScript
  Description : Create an array of unique values, in order, from the
input arrays

Bug#843065: ITP: node-array-differ -- Create an array with values that are present in the first input array but not additional ones

[Sruthi Chandran]

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

* Package name: node-array-differ
  Version : 2.0.3
  Upstream Author : Sindre Sorhus 
(sindresorhus.com)
* URL : https://github.com/sindresorhus/array-differ#readme
* License : Expat
  Programming Lang: JavaScript
  Description : Create an array with values that are present in the
first input array but not additional ones

Bug#843067: ITP: node-arrify -- Convert a value to an array

[Sruthi Chandran]

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

* Package name: node-arrify
  Version : 1.0.1
  Upstream Author : Sindre Sorhus 
(sindresorhus.com)
* URL : https://github.com/sindresorhus/arrify#readme
* License : Expat
  Programming Lang: JavaScript
  Description : Convert a value to an array

Re: Bug#843021: RFP: yarn -- a fast, reliable, and secure package manager for Node.js

[Lars Wirzenius]

On Thu, Nov 03, 2016 at 04:17:37PM +0100, Paolo Greppi wrote:
> On 03/11/2016 15:28, Lars Wirzenius wrote:
> > The JS package manager called yarn is quite new. It wouldn't be
> > unreasonable to suggest to them to rename it to avoid a naming
> > conflict, in my opinion.
> 
> Fine, I have opened an "Issue" in the github tracker, let's see if this
> is received constructively:
> https://github.com/yarnpkg/yarn/issues/1656

Upstream seems to not want to change the name. They closed that bug
with the following explanation:

# We don't have any intentions of using the yarnpkg binary as the sole
# one. There's prior art here with Node.js using node instead of
# nodejs even though there's already a Debian package called node. See
# #673 for more information.

The upstream 673 bug doesn't actually contain an explanation, though.

I see the following possibilities now:

a) You rename the yarn package manager in Debian (both package and
   binary). I keep the yarn name for my program and package.

b) We both rename. Nobody uses the name yarn, either as package or as
   a binary name.

I'm not happy if I have to give up the yarn name. I find it unfair
that I have to rename just because some new upstream decides to use I
name I've already been using for years, and refuses to reconsider
their use of the name.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Re: Bug#843021: RFP: yarn -- a fast, reliable, and secure package manager for Node.js

[Paolo Greppi]

On 03/11/2016 17:54, Lars Wirzenius wrote:
> I see the following possibilities now:
> 
> a) You rename the yarn package manager in Debian (both package and
>binary). I keep the yarn name for my program and package.
> 
> b) We both rename. Nobody uses the name yarn, either as package or as
>a binary name.

I'd go for a).

It is clear that this package will install /usr/bin/yarnpkg binary only.
The package itself should be yarnpkg or node-yarnpkg.

Should I just retitle this bug ?




signature.asc
Description: OpenPGP digital signature

Re: Bug#843021: RFP: yarn -- a fast, reliable, and secure package manager for Node.js

[Lars Wirzenius]

On Thu, Nov 03, 2016 at 06:04:26PM +0100, Paolo Greppi wrote:
> On 03/11/2016 17:54, Lars Wirzenius wrote:
> > I see the following possibilities now:
> > 
> > a) You rename the yarn package manager in Debian (both package and
> >binary). I keep the yarn name for my program and package.
> > 
> > b) We both rename. Nobody uses the name yarn, either as package or as
> >a binary name.
> 
> I'd go for a).
> 
> It is clear that this package will install /usr/bin/yarnpkg binary only.
> The package itself should be yarnpkg or node-yarnpkg.

Cool. Thank you.

> Should I just retitle this bug ?

Retitling the bug report is probably a convenience to those reading it
later, but the important bit is that the package and binary names are
correct when you upload.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Bug#843075: ITP: hydra-el -- make Emacs bindings that stick around

[Lev Lamberov]

Package: wnpp
Severity: wishlist
Owner: Lev Lamberov 

* Package name: hydra-el
  Version : 0.13.6
  Upstream Author : Oleh Krehel 
* URL : https://github.com/abo-abo/hydra
* License : GPL-3+
  Programming Lang: Emacs Lisp
  Description : make Emacs bindings that stick around

This is a package for GNU Emacs that can be used to tie related commands into
a family of short bindings with a common prefix - a Hydra. Once you summon
your Hydra through the prefixed binding (the body + any one head), all heads
can be called in succession with only a short extension. Hydra can be vanished
with any binding that isn't the Hydra's head (and that binding will call a
proper command too). This makes the Hydra very seamless, it's like a minor
mode that disables itself automagically.

Bug#843076: ITP: node-multimatch -- Extends minimatch.match() with support for multiple patterns

[Sruthi Chandran]

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

* Package name: node-multimatch
  Version : 2.1.0
  Upstream Author : Sindre Sorhus 
(http://sindresorhus.com)
* URL : https://github.com/sindresorhus/multimatch
* License : Expat
  Programming Lang: JavaScript
  Description : Extends minimatch.match() with support for multiple
patterns

Re: Lots and lots of tiny node.js packages [and 1 more messages]

[Ian Jackson]

Antonio Terceiro writes ("Re: Lots and lots of tiny node.js packages"):
> This is not a personal response to you, I am just pigging back on your
> email.
...
> As a regular reader of debian-devel, I must say I am frustrated by this
> discussion being raised yet another time.

I can see why this is frustrating.  I posted because I didn't feel
that the previous discussions had produced what I considered a
sensible answer.

I'm sorry to have added to your (and, no doubt, others') feelings of
negativity, tiredness etc.

This kind of thing is one of the consequences of the project's
dysfunctional decisionmaking processes.

Russ Allbery writes ("Re: Lots and lots of tiny node.js packages"):
> There have been various efforts to aggregate tiny packages together into
> larger packages in the past.  I'm familiar with some of those efforts on
> the Perl team.  My impression is that, in every case where upstream was
> not doing the same aggregation, the result has been somewhere between
> uncomfortably awkward and a disaster.  [much snipped]

Thanks, Russ, for a very good answer to my question.

Can we keep it somewhere ?

Thanks,
Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Bug#843021: RFP: yarn -- a fast, reliable, and secure package manager for Node.js

[Ian Jackson]

Lars Wirzenius writes ("Re: Bug#843021: RFP: yarn -- a fast, reliable, and 
secure package manager for Node.js"):
> On Thu, Nov 03, 2016 at 02:02:31PM +, Ian Jackson wrote:
> > I searched github for `yarn'.
> 
> You don't find my software on github. I do not want to rely on
> non-free services like github.

Indeed.  Mine neither.  But it's a way of finding out what already
might exist when choosing a name.

Of course another answer would be that someone choosing a command name
ought to search something like this:

  
https://packages.debian.org/search?searchon=contents&keywords=%2Fyarn&mode=path&suite=unstable&arch=any

which readily shows your yarn, of course.

> > There are lots of hits for other
> > programs, including: [...]
> 
> How many of those were public in mid-2013?

I have no idea.

> > Obviously "yarn" is a really bad name.  Someone who picks a name like
> > that must obviously expect that they can't necessarily have that name
> > in every namespace.
> 
> When I chose the name in 2013, I didn't other software that was called
> yarn.

Fair enough.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

DEP14 policy for two dots

[Nish Aravamudan]

[ Raphael, apologies for sending twice, had a error in the headers in
the prior one ]

Not sure exactly where to ask this better than debian-devel, but I am
working on an importer for the Ubuntu Server team which parses published
versions of source packages in Debian and Ubuntu. I ran into an issue
today where there is a published version of src:pcre3 with version
'8.30..2'. `man git-check-ref-format` says that reference names "cannot
have two consecutive dots ..  anywhere." DEP14 specifies appropriate
substitutions for : and ~, but it seems like .. should also be accounted
for so I can correctly tag historic versions?

Thanks,
Nish

-- 
Nishanth Aravamudan
Ubuntu Server
Canonical Ltd

Re: Lots and lots of tiny node.js packages [and 1 more messages]

[Arturo Borrero Gonzalez]

On 3 November 2016 at 18:50, Ian Jackson
 wrote:
>
> Thanks, Russ, for a very good answer to my question.
>
> Can we keep it somewhere ?
>

just created this:

https://wiki.debian.org/TinyPackages

feel free to add more content.

unattended-upgrades by default?

[Steve McIntyre]

Hey folks,

I'm in Seattle for the Debian Cloud sprint and it's going really
well. I'll post a report in a few days summarising what we've
done. But, in the meantime, there's something that has come up which I
think merits wider discussion.

One of the topics that we've been talking about yesterday is automatic
software upgrades of cloud images. Some of the cloud platform
providers really want this so that unsophisticated / inexperienced
users of Debian images on their platforms will be secure by
default. But there are potential issues here:

 * if users are providing a service like a database from a cloud
   instance, there may be unexpected (potentially lengthy) downtime if
   upgrades happen. Of course, this can be mitigated by disabling the
   upgrade job on those machines if desired but that needs people to
   know to do this. Experienced users will probably be dealing with
   upgrades already, so this should not be an issue.

 * it will be a different experience compared to what people will get
   when installing Debian normally, using d-i / debootstrap. Most
   (all?) of our desktop environments already have some automatic
   notification of available updates, but (a) not everybody uses them;
   and (b) that's not so useful on a remote server installation where
   there's no desktop for the system to show a pop-up or similar.

To solve the issue and provide security updates by default, I'm
proposing that we should switch to installing unattended-upgrades by
default (and enabling it too) *unless* something else in the
installation is already expected to deal with security updates.

Thoughts?

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"I suspect most samba developers are already technically insane... Of
 course, since many of them are Australians, you can't tell." -- Linus Torvalds

Re: unattended-upgrades by default?

[Mathieu Parent (Debian)]

2016-11-03 19:47 GMT+01:00 Steve McIntyre :
> Hey folks,

Hello,

[...]
> To solve the issue and provide security updates by default, I'm
> proposing that we should switch to installing unattended-upgrades by
> default (and enabling it too) *unless* something else in the
> installation is already expected to deal with security updates.
>
> Thoughts?

+1.

Ubuntu does a similar thing. See
https://patches.ubuntu.com/p/pkgsel/pkgsel_0.43ubuntu2.patch for how
(but does pkgsel applies to cloud image creation?).

Regards
-- 
Mathieu Parent

Re: DEP14 policy for two dots

[Ian Jackson]

Nish Aravamudan writes ("DEP14 policy for two dots"):
> [ Raphael, apologies for sending twice, had a error in the headers in
> the prior one ]
> 
> Not sure exactly where to ask this better than debian-devel, but I am
> working on an importer for the Ubuntu Server team which parses published
> versions of source packages in Debian and Ubuntu. I ran into an issue
> today where there is a published version of src:pcre3 with version
> '8.30..2'. `man git-check-ref-format` says that reference names "cannot
> have two consecutive dots ..  anywhere." DEP14 specifies appropriate
> substitutions for : and ~, but it seems like .. should also be accounted
> for so I can correctly tag historic versions?

Urk.  How exciting.  I think we may need a more general escaping
scheme for these and other weirdnesses.

I have an interest as dgit uses DEP-14 tag escaping.  I have CC'd the
vcs-pkg list.


tl;dr: I think we should insert `#' characters as needed.


Looking at git-check-ref-format(1) and
https://wiki.debian.org/Punctuation:

  .special to git, generally permitted in versions,
   and we want it usually to be literal - this is our problem

  ~special to git, permitted in versions, handled by DEP-14 as _
  :special to git, epoch in versions, handled by DEP-14 as %

  @special to git (although sometimes allowed), forbidden in versions

  % _  not special to git but already used by DEP-14

  # , =
   not mentioned in the git manual as special, forbidden in versions

  ]not special to git, although [ is so let's not, eh ?

  + -  not special to git, permitted in versions

  " ' $ & ( ) * ; < > ? `
   not mentioned in the git manual but troublesome shell
   metacharacters which we would be insane to use here

  [ / { }
   interpreted specially by git some of the time,
   forbidden in versions - not really useful

  ^ ? * \
   all of these are forbiden by git, not permitted in versions

So I think in fact the only thing we have a problem with is multiple
dots.  Looking at the summary above, we have the choice of one of
these:

  #   Its use as a shell comment character is fine, because when inside
  a version tag it is always preceded by some string like
  "debian/" or "upstream/".  We would almost never need to put it
  at the start of the encoded version string anyway, and we have
  already tolerated a similar situation with ~.

  There is possible confusion with HTML fragment identifiers, and
  possibly in languages other than shell which use # for
  comments (athough hopefuly they aren't dealing with our versions
  as literals anyway).

   Proposed rule:

   Insert "#":
  - between each pair of adjacent dots
  - after any trailing dot
  - before any leading dot

   Examples:
8.30..2 => 8.30.#.2
8.30.   => 8.30.#
.42 => #.42

  ,   I would like to avoid this because lots of people are probably
  using it as a list separator in ways that are difficult for us
  to predict.  If we used it, I would suggest the same as for #.

  =   In principle we could use this.  I don't like it for a similar
  reason to above.  If we did use it it might look a bit like
  Q-P encoding in some contexts.

  @   We could use this although I wouldn't like to rely on the fact
  that git dislikes `@{' and `@' but not @ followed by other
  things.

  % Reusing this is tempting because an epoch separator can never
  follow `.', so any `%' after any `.' would unambiguously mean
  `escape for dot rather than colon'.  But in principle `.' can
  occur at the start of the version, so `:3' and `.3' both =>
  `%3'.  There would have to be some horror of an exception rule.
  (Although `:3' and `3' compare equal as Debian versions, they
  are different textual strings and the tag needs to convey the
  whole string.)

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: DEP14 policy for two dots

[Nish Aravamudan]

On 03.11.2016 [19:37:41 +], Ian Jackson wrote:
> Nish Aravamudan writes ("DEP14 policy for two dots"):
> > [ Raphael, apologies for sending twice, had a error in the headers in
> > the prior one ]
> > 
> > Not sure exactly where to ask this better than debian-devel, but I am
> > working on an importer for the Ubuntu Server team which parses published
> > versions of source packages in Debian and Ubuntu. I ran into an issue
> > today where there is a published version of src:pcre3 with version
> > '8.30..2'. `man git-check-ref-format` says that reference names "cannot
> > have two consecutive dots ..  anywhere." DEP14 specifies appropriate
> > substitutions for : and ~, but it seems like .. should also be accounted
> > for so I can correctly tag historic versions?
> 
> Urk.  How exciting.  I think we may need a more general escaping
> scheme for these and other weirdnesses.
> 
> I have an interest as dgit uses DEP-14 tag escaping.  I have CC'd the
> vcs-pkg list.

Thank you, I should have thought of that!

> tl;dr: I think we should insert `#' characters as needed.

Thank you as well for your excellent analysis of the options. I think
the proposal 

>Proposed rule:
> 
>Insert "#":
>   - between each pair of adjacent dots
>   - after any trailing dot
>   - before any leading dot
> 
>Examples:
> 8.30..2 => 8.30.#.2
> 8.30.   => 8.30.#
> .42 => #.42

is very reasonable and I assume could be added to DEP14 itself?
Presuming broader agreement, of course. For the purpose of 'ubuntu/'
tagging in our tool, we would adopt the same rule.

Thank,s
Nish

-- 
Nishanth Aravamudan
Ubuntu Server
Canonical Ltd

Re: Lots and lots of tiny node.js packages [and 1 more messages]

[Ian Jackson]

Arturo Borrero Gonzalez writes ("Re: Lots and lots of tiny node.js packages 
[and 1 more messages]"):
> On 3 November 2016 at 18:50, Ian Jackson
> just created this:
> 
> https://wiki.debian.org/TinyPackages

Thanks.  That's already useful.

Ian.


-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: unattended-upgrades by default?

[Lars Wirzenius]

On Thu, Nov 03, 2016 at 06:47:28PM +, Steve McIntyre wrote:
> One of the topics that we've been talking about yesterday is automatic
> software upgrades of cloud images. Some of the cloud platform
> providers really want this so that unsophisticated / inexperienced
> users of Debian images on their platforms will be secure by
> default. But there are potential issues here:

I am in favour of enabling automatic updates, particularly security
updates, on clould images by default. In fact, I wouldn't mind having
them on all types of installation by default. In my opinion, the
ecosystem-wide security benefits of having Debian systems keep up to
date with security updates by default overweigh any inconvenience of
having to tweak system configuration on hosts where the automatic
updates are problematic.

If we do this, we should prominently note it in release notes and have
a (wiki) page that explains how to turn off the automatic updates.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Re: Lots and lots of tiny node.js packages

[Bernd Zeimetz]

On 11/02/2016 11:59 AM, Scott Leggett wrote:
> Actually, node is in a league of its own in this regard:
> 
> http://www.modulecounts.com/

492 new modules per day? are we sure we even want to start to package
something like that!???


> 

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



signature.asc
Description: OpenPGP digital signature

Re: Lots and lots of tiny node.js packages

[Christian Seiler]

On 11/03/2016 09:37 PM, Bernd Zeimetz wrote:
> On 11/02/2016 11:59 AM, Scott Leggett wrote:
>> Actually, node is in a league of its own in this regard:
>>
>> http://www.modulecounts.com/
> 
> 492 new modules per day? are we sure we even want to start to package
> something like that!???

I don't think anybody here suggested packaging the entirety of the
node.js ecosystem - same as with other packaging ecosystems as well.
There are more CPAN packages than Debian source packages.

Currently there are ~3500 source packages in the archive that end in
-perl, while there are ~550 packages in the archive that
Build-Depend on anything with 'node' in it. Those numbers are only
an estimate, but do show that we are by far not in a place where
this has gone overboard.

While I do have a lot of misgivings about how the entire ecosystem
works upstream (same as with many other people in this thread),
there are very legitimate reasons to want JavaScript software in
Debian. And as long as the number of node packages in Debian doesn't
surpass those of other languages, even if many packages are
ridiculously small, I think the concern about 'number of packages'
just isn't backed by evidence.

Regards,
Christian

Bug#843106: ITP: libjloda-java -- Java library of data structures and algorithms for bioinformatics

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: libjloda-java
  Version : 0.0+20161018
  Upstream Author : Daniel Huson 
* URL : https://github.com/danielhuson/jloda
* License : GPL
  Programming Lang: Java
  Description : Java library of data structures and algorithms for 
bioinformatics
 The jloda Java library provides some basic data structures and
 algorithms used by bioinformatics applications like SplitsTree,
 Dendroscope and MEGAN.


Remark: This Java library is needed to package MALT and MEGAN which are
two well known programs in bioinformatics and recently published under
a free license.  It will be maintained by the Debian Med team at
   https://anonscm.debian.org/git/debian-med/libjloda-java.git

Re: Lots and lots of tiny node.js packages

[Bernd Zeimetz]

On 11/02/2016 02:04 AM, Russ Allbery wrote:
> There have been various efforts to aggregate tiny packages together into
> larger packages in the past.  I'm familiar with some of those efforts on
> the Perl team.  My impression is that, in every case where upstream was
> not doing the same aggregation, the result has been somewhere between
> uncomfortably awkward and a disaster.

We have an even worse situation with nagios-plugins-contrib - various
upstreams, various (often weird) download locations and a mix plugins
from single tiny scripts to stuff that uses automake, flex and others to
build plugins.
The solution was a bit of python code, a generic makefile and we even
have a 'uscan' replacement.

The gory details are described in
https://raw.githubusercontent.com/bzed/pkg-nagios-plugins-contrib/master/debian/README.source
in case you're interested.

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

Re: Lots and lots of tiny node.js packages

[Russ Allbery]

Bernd Zeimetz  writes:
> On 11/02/2016 02:04 AM, Russ Allbery wrote:

>> There have been various efforts to aggregate tiny packages together
>> into larger packages in the past.  I'm familiar with some of those
>> efforts on the Perl team.  My impression is that, in every case where
>> upstream was not doing the same aggregation, the result has been
>> somewhere between uncomfortably awkward and a disaster.

> We have an even worse situation with nagios-plugins-contrib - various
> upstreams, various (often weird) download locations and a mix plugins
> from single tiny scripts to stuff that uses automake, flex and others to
> build plugins.

> The solution was a bit of python code, a generic makefile and we even
> have a 'uscan' replacement.

> The gory details are described in
> https://raw.githubusercontent.com/bzed/pkg-nagios-plugins-contrib/master/debian/README.source
> in case you're interested.

Ah, interesting.  That's the first success story I've heard.  Have you had
any trouble with confused users who can't figure out if they have the
right version of some upstream plugin?  (I suppose that's a bit less of a
problem for this since no one cares about Build-Depends, etc., for
plugins, and mostly people just run whatever we package and don't worry
about it.)

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

Re: Lots and lots of tiny node.js packages

[Bernd Zeimetz]

On 11/03/2016 10:48 PM, Russ Allbery wrote:

>> The gory details are described in
>> https://raw.githubusercontent.com/bzed/pkg-nagios-plugins-contrib/master/debian/README.source
>> in case you're interested.
> 
> Ah, interesting.  That's the first success story I've heard.  Have you had
> any trouble with confused users who can't figure out if they have the
> right version of some upstream plugin?  (I suppose that's a bit less of a
> problem for this since no one cares about Build-Depends, etc., for
> plugins, and mostly people just run whatever we package and don't worry
> about it.)

The biggest "problems" we had were
- users who reported bugs against plugins in the packaging issue tracker
on github instead of the upstream bugtracker
- users sending pull requests with changes that modify the plugin code
directly, we prefer to keep all patches in debian/patches/$plugin
- bug reports of fedora people complaining that plugins written for
Debian don't work on their box :D
- plugins changing the way they handle options from one version to the
other. While this is not such a big issue from one debian release to the
next one, as people normally expect some breakages, it might be annoying
for backports users.

so far nobody complained/discussed plugin versions - but most of them
are moving slowly, also we (at least try to) provide always updated
backports.


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

Re: unattended-upgrades by default?

[Russell Stuart]

On Thu, 2016-11-03 at 18:47 +, Steve McIntyre wrote:
> To solve the issue and provide security updates by default, I'm
> proposing that we should switch to installing unattended-upgrades by
> default (and enabling it too) *unless* something else in the
> installation is already expected to deal with security updates.

I am amazed we don't do this already.  Effectively it makes us insecure
by default.

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

Re: unattended-upgrades by default?

[Stefano Zacchiroli]

On Thu, Nov 03, 2016 at 06:47:28PM +, Steve McIntyre wrote:
> To solve the issue and provide security updates by default, I'm
> proposing that we should switch to installing unattended-upgrades by
> default (and enabling it too)

Please do. I've been doing this for ages on all my Debian machines, and
never regretted it.

Yes, in some cases you do not want unattended-upgrades for reasons like
those you mentioned, but those are the special cases, not the default.
We should just prominently document the change, so that users that need
to avoid unattended-upgrades know how to do so.

Thanks for bringing up this topic,
Cheers.
-- 
Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o
Computer Science Professor . CTO Software Heritage . . . . . o . . . o o
Former Debian Project Leader . OSI Board Director  . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »

Re: unattended-upgrades by default?

[Martin Zobel-Helas]

Hi, 

On Thu Nov 03, 2016 at 18:47:28 +, Steve McIntyre wrote:
> Hey folks,
> 
> I'm in Seattle for the Debian Cloud sprint and it's going really
> well. I'll post a report in a few days summarising what we've
> done. But, in the meantime, there's something that has come up which I
> think merits wider discussion.
> 
> One of the topics that we've been talking about yesterday is automatic
> software upgrades of cloud images. Some of the cloud platform
> providers really want this so that unsophisticated / inexperienced
> users of Debian images on their platforms will be secure by
> default. But there are potential issues here:
> 
>  * if users are providing a service like a database from a cloud
>instance, there may be unexpected (potentially lengthy) downtime if
>upgrades happen. Of course, this can be mitigated by disabling the
>upgrade job on those machines if desired but that needs people to
>know to do this. Experienced users will probably be dealing with
>upgrades already, so this should not be an issue.
> 
>  * it will be a different experience compared to what people will get
>when installing Debian normally, using d-i / debootstrap. Most
>(all?) of our desktop environments already have some automatic
>notification of available updates, but (a) not everybody uses them;
>and (b) that's not so useful on a remote server installation where
>there's no desktop for the system to show a pop-up or similar.
> 
> To solve the issue and provide security updates by default, I'm
> proposing that we should switch to installing unattended-upgrades by
> default (and enabling it too) *unless* something else in the
> installation is already expected to deal with security updates.
> 
> Thoughts?

+1! 

One side mark: once we start that, we might expose users to the public
that they run this, as then a lot of users will send a similar sized
packets to the internet! But i see no real security concern with that.

Cheers,
Martin
-- 
 Martin Zobel-Helas Debian System Administrator
 Debian & GNU/Linux Developer   Debian Listmaster
 http://about.me/zobel   Debian Webmaster
 GPG Fingerprint:  6B18 5642 8E41 EC89 3D5D  BDBB 53B1 AC6D B11B 627B 

Re: OpenSSL 1.1.0

[Ian Jackson]

Kurt Roeckx writes ("OpenSSL 1.1.0"):
> I just uploaded OpenSSL 1.1.0 to unstable. There are still many
> packages that fail to build using OpenSSL 1.1.0. For most packages
> it should be easy to migrate 1.1.0. The most common problems when
> going to OpenSSL 1.1.0 are:
> - configure trying to detect a function that's now a macro.
> - Accessing members of structures that have now become opaque. You
>   now need to use function to get or set them.

I'm concerned that we are setting up a situation where:

 * A maintainer (or interested party) for a package which peripherally
   uses openssl;
 * Gets an RC bug report;
 * Is threatened with autoremoval;
 * Does not really know how to respond;
 * Does not have useful support from their own upstream because
   their own upstream hasn't got to grips with this yet;
 * Feels under pressure that they must Fix It Now.

This seems to be setting ourselves up for failures - particularly,
failures where the package compiles and seems to work, but has some
kind of problem in its use of openssl APIs which constitutes a
security problem.

Maintainers who feel pressured may well apply patches which have not
had the level of review or discussion that would normally be
appropriate.  In security-sensitive code this is unfortunate.

There doesn't seem to be any way for a maintainer who is unsure to get
a review of a proposed patch to their package.  This is particularly
true when upstreams don't have patches - which seems to be true for
many packages (even BIND, say, only had them very recently).

Nor do we have any coherent tracking of what ad-hoc patches we are
(collectively) rushing to apply.

The use of RC bug status is a very strong imperative to maintainers.
I worry that we haven't really thought through the implications.

In general any large-scale transition like this needs to take into
account not only the technical goals, but also the best way to get the
best quality work out of our contributors.  I worry that the current
process is likely to encourage hasty actions.

If the process we have adopted results in security bugs, it will not
be enough to blame the poor maintainer who felt they had no
alternative.

Thanks for your attention.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Work-needing packages report for Nov 4, 2016

[wnpp]

The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.

Total number of orphaned packages: 989 (new: 17)
Total number of packages offered up for adoption: 153 (new: 0)
Total number of packages requested help for: 48 (new: 0)

Please refer to http://www.debian.org/devel/wnpp/ for more information.



The following packages have been orphaned:

   accountsservice (#842851), orphaned 2 days ago
 Description: query and manipulate user account information
 Reverse Depends: accountsservice budgie-core cinnamon
   cinnamon-control-center gdm3 gir1.2-accountsservice-1.0
   gnome-control-center gnome-initial-setup gnome-shell
   libaccountsservice-dbg (3 more omitted)
 Installations reported by Popcon: 69465
 Bug Report URL: http://bugs.debian.org/842851

   apf-firewall (#842966), orphaned yesterday
 Description: easy iptables based firewall system
 Installations reported by Popcon: 113
 Bug Report URL: http://bugs.debian.org/842966

   binclock (#842557), orphaned 4 days ago
 Description: binary clock for console with color support
 Installations reported by Popcon: 51
 Bug Report URL: http://bugs.debian.org/842557

   csstidy (#842594), orphaned 4 days ago
 Description: CSS parser and optimiser
 Installations reported by Popcon: 542
 Bug Report URL: http://bugs.debian.org/842594

   gengetopt (#842941), orphaned yesterday
 Description: skeleton main.c generator
 Installations reported by Popcon: 218
 Bug Report URL: http://bugs.debian.org/842941

   laborejo (#842587), orphaned 4 days ago
 Description: music notation workshop
 Installations reported by Popcon: 102
 Bug Report URL: http://bugs.debian.org/842587

   launchy (#843057), orphaned today
 Description: smart search launcher for installed programs or files
 Reverse Depends: launchy-plugins
 Installations reported by Popcon: 100
 Bug Report URL: http://bugs.debian.org/843057

   libacpi (#842559), orphaned 4 days ago
 Description: general purpose library for ACPI
 Reverse Depends: acpitail libacpi-dev yacpi
 Installations reported by Popcon: 592
 Bug Report URL: http://bugs.debian.org/842559

   mod-spamhaus (#842967), orphaned yesterday
 Description: Apache DNSBL module that blocks listed IP addresses
 Installations reported by Popcon: 43
 Bug Report URL: http://bugs.debian.org/842967

   nitrogen (#842558), orphaned 4 days ago
 Description: wallpaper browser and changing utility for X
 Installations reported by Popcon: 795
 Bug Report URL: http://bugs.debian.org/842558

   python-leveldb (#842942), orphaned yesterday
 Description: Python wrapper for LevelDB
 Installations reported by Popcon: 227
 Bug Report URL: http://bugs.debian.org/842942

   sockstat (#842489), orphaned 5 days ago
 Description: view detailed information about open connections
 Installations reported by Popcon: 347
 Bug Report URL: http://bugs.debian.org/842489

   system-storage-manager (#842968), orphaned yesterday
 Description: system storage management tool
 Installations reported by Popcon: 151
 Bug Report URL: http://bugs.debian.org/842968

   tsocks (#842555), orphaned 4 days ago
 Description: transparent network access through a SOCKS 4 or 5 proxy
 Installations reported by Popcon: 1548
 Bug Report URL: http://bugs.debian.org/842555

   w3-recs (#842472), orphaned 5 days ago (non-free)
 Description: search for a new maintainer
 Installations reported by Popcon: 206
 Bug Report URL: http://bugs.debian.org/842472

   yacpi (#842556), orphaned 4 days ago
 Description: ncurses based acpi monitor for text mode
 Installations reported by Popcon: 227
 Bug Report URL: http://bugs.debian.org/842556

   yafc (#842553), orphaned 4 days ago
 Description: yet another FTP client
 Installations reported by Popcon: 255
 Bug Report URL: http://bugs.debian.org/842553

972 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/orphaned for a complete list.



No new packages have been given up for adoption, but a total of 153 packages
are awaiting adoption.  See http://www.debian.org/devel/wnpp/rfa_bypackage
for a complete list.



For the following packages help is requested:

   athcool (#278442), requested 4391 days ago
 Description: Enable powersaving mode for Athlon/Duron processors
 Installations reported by Popcon: 20
 Bug Report URL: http://bugs.debian.org/278442

   awstats (#755797), requested 834 days ago
 Description: powerful and featureful web server log analyzer
 Installations reported by Popc

Bug#843120: ITP: freight -- easy-to-understand shell script to handle APT repositories

[Nicolas Braud-Santoni]

Package: wnpp
Severity: wishlist
Owner: Nicolas Braud-Santoni 

* Package name: freight
  Version : 0.3.9
  Upstream Author : The Freight Team
* URL : https://github.com/freight-team/freight#freight
* License : BSD-2-clause
  Programming Lang: SH
  Description : easy-to-understand shell script to handle APT repositories
 freight is an easy-to-use and to understand shell script for
 building packages and keeping them in an up-to-date and signed
 reporitory.
 .
 freight can be compared, in terms of scope and features,
 to reprepro(1), but is simpler to setup and maintain.

I am adopting the source package from my friend Christian Pointner,
with the intent to maintain it inside Debian.

Bug#843123: ITP: r-cran-htmltable -- GNU R package for advanced html tables

[Dirk Eddelbuettel]

Package: wnpp
Owner: Dirk Eddelbuettel 
Severity: wishlist

* Package name: r-cran-htmltable
  Version : 1.7-1
  Upstream Author : Max Gordon
* URL or Web page : https://cran.r-project.org/package=htmlTable
* License : GPL-3
  Description : GNU R package for advanced html tables

This is a new dependency of the existing package r-cran-hmisc.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#843124: ITP: r-cran-viridis -- GNU R package with color maps from matplotlib

[Dirk Eddelbuettel]

Package: wnpp
Owner: Dirk Eddelbuettel 
Severity: wishlist

* Package name: r-cran-viridis
  Version : 0.3.4-1
  Upstream Author : Simon Garnier 
* URL or Web page : https://cran.r-project.org/package=viridis
* License : MIT
  Description : GNU R package with color maps from matplotlib

This is a new dependency of the existing package r-cran-hmisc.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#843125: ITP: python3-openflow -- low level library to parse OpenFlow messages

[Paulo Henrique de Lima Santana (phls)]

Package: wnpp
Severity: wishlist
Owner: "Paulo Henrique de Lima Santana (phls)" 

* Package name: python3-openflow
  Version : 1.1.0~alpha2
  Upstream Author : Kytos Development Team 
* URL : https://github.com/kytos/python-openflow
* License : MIT
  Programming Lang: Python
  Description : low level library to parse OpenFlow messages

 If you want to read an OpenFlow packet from an open socket or send a message
 to an OpenFlow switch, this is your best friend. The main features are:
 high performance, latest specification compliance, short learning curve and
 free software license.
 .
 This library is part of Kytos project, a collaborative project between
 SPRACE (from São Paulo State University, Unesp) and Caltech (California
 Institute of Technology). python-openflow was developed to be used with
 Kytos controller, but feel free to use this simple and intuitive library
 in another project with another controller.