Re: Crowd funding campaign to package browserify in debian

[Pirate Praveen]

On Wednesday 12 October 2016 11:09 PM, Pirate Praveen wrote:
> Hi,
> 
> We have been discussing browserified javascript situation in debian for
> sometime. We decided to spent one full month on packaging browserify if
> we can raise enough money via crowd funding. See
> http://igg.me/at/debian-browserify for more details.

With 11 days left for the campaign and raising 14% of the target from 8
backers, we already spent 15 days and 2 hours (I spent 7 days 3 hours
/59 hours and Sruthi spent 7 days 7 hours/63 hours) and have packaged 96
node modules so far.

> Note: Some packages would still need grunt or gulp I think, but probably
> with some changes they could be briwserified using browserify itself.
> 

We shifted out focus to grunt from browserify realizing grunt is needed
by more packages.

You can compare these two pages,

Before we started this campaign
https://wiki.debian.org/Javascript/Nodejs/Tasks/grunt?action=recall&rev=26

As of yesterday
https://wiki.debian.org/Javascript/Nodejs/Tasks/grunt?action=recall&rev=38

Latest status https://wiki.debian.org/Javascript/Nodejs/Tasks/grunt



signature.asc
Description: OpenPGP digital signature

Bug#842782: ITP: node-base -- base is the foundation for creating modular, unit testable and highly pluggable node.js applications

[Sruthi Chandran]

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

* Package name: node-base
  Version : 0.11.1
  Upstream Author : Jon Schlinkert (https://github.com/jonschlinkert)
* URL : https://github.com/node-base/base
* License : Expat
  Programming Lang: JavaScript
  Description : base is the foundation for creating modular, unit
testable and highly pluggable node.js applications, starting with a
handful of common methods, like `set`, `get`, `del` and `use`

Bug#842783: ITP: node-parse-glob -- Parse a glob pattern into an object of tokens

[Sruthi Chandran]

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

* Package name: node-parse-glob
  Version : 3.0.4
  Upstream Author : Jon Schlinkert (https://github.com/jonschlinkert)
* URL : https://github.com/jonschlinkert/parse-glob
* License : Expat
  Programming Lang: JavaScript
  Description : Parse a glob pattern into an object of tokens

Bug#842784: ITP: mapcode -- Convert coordinates to/from mapcode

[Stefan Fritsch]

Package: wnpp
Severity: wishlist
Owner: Stefan Fritsch 

* Package name: mapcode
  Version : 2.5.0
  Upstream Author : Stichting Mapcode Foundation (http://www.mapcode.com)
* URL : https://github.com/mapcode-foundation/mapcode-cpp
* License : Apache 2.0
  Programming Lang: C++
  Description : Convert geo coordinates to/from mapcodes

A mapcode represents a location. Every location on Earth can be
represented by a mapcode. Mapcodes were designed to be short, easy to
recognise, remember and communicate. They are precise to a few meters,
which is good enough for every-day use. Locations in densely populated
areas often get shorter mapcodes. See http://www.mapcode.com/

This package contains a command line utility that can convert to and
from mapcodes.


The source also builds a static library. If there is demand, this could
later be put into a separate binary package (maybe as a dynamic lib).

Bug#842788: ITP: expand-region-el -- increase selected region by semantic units

[Lev Lamberov]

Package: wnpp
Severity: wishlist
Owner: Lev Lamberov 

* Package name: expand-region-el
  Version : 0.11.0
  Upstream Author : Magnar Sveen 
* URL : https://github.com/magnars/expand-region.el
* License : GPL-3+
  Programming Lang: Emacs Lisp
  Description : increase selected region by semantic units

Expand region increases the selected region by semantic units. Just keep
pressing the key until it selects what you want.

Expand region works fairly well with most languages, due to the general
nature of the basic expansions. However, most languages also will benefit
from some specially crafted expansions. You can add your own expansions to the
languages of your choice simply by creating a function that looks around point
to see if it's inside or looking at the construct you want to mark, and if
so - mark it.

Bug#842793: ITP: ooniprobe-wui -- Web assets for ooniprobe

[Iain R. Learmonth]

Package: wnpp
Severity: wishlist
Owner: "Iain R. Learmonth" 

* Package name: ooniprobe-wui
  Version : 2.0.1
  Upstream Author : Tor Project
* URL : https://github.com/TheTorProject/ooni-wui
* License : pending
  Programming Lang: JavaScript
  Description : Web assets for ooniprobe

OONI, the Open Observatory of Network Interference, is a global observation
network which aims to collect high quality data using open methodologies and
free software to share observations and data about the various types, methods,
and amounts of network tampering in the world.

ooniprobe is a program to probe a network and collect data for the OONI
project. It will test the current network for signs of surveillance and
censorship.

This package contains the web assets for ooniprobe.

--

This is packaged seperately as the ooniprobe source distribution contains
binary snapshots of the web assets, and does not include the sources for them
which are in a seperate git repo.

Bug#842799: ITP: tendermint-go-db -- Tendermint key-value database

[Alessio Treglia]

Package: wnpp
Severity: wishlist
Owner: Alessio Treglia 

* Package name: tendermint-go-db
  Version : 0.0~git20160508.0.31fdd21-1
  Upstream Author : Tendermint
* URL : https://github.com/tendermint/go-db
* License : GPL-3.0
  Programming Lang: Go
  Description : Tendermint key-value database

 Tendermint Core is Byzantine Fault Tolerant (BFT) middleware
 that takes a state transition machine, written in any
 programming language, and replicates it on many machines.
 .
 This package provides the library used by several Tendermint
 components to handle key-value data stores.

Re: Rebuilds with unexpected timestamps

[Ian Jackson]

Adrian Bunk writes ("Re: Rebuilds with unexpected timestamps"):
> On Sun, Oct 30, 2016 at 11:48:56PM +, Simon McVittie wrote:
> >...
> > * Source for generated files in the tarball: should be in both git
> >   and tarball, but sometimes mistakenly omitted from tarballs
> >   (e.g. configure.ac, m4/foo.m4,
> >   build-aux/git-version-gen). Leaving these out of the tarball is
> >   also an upstream bug, IMO, because it means the "source" tarball
> >   is not really its own source. I'd suggest sending patches
> >   upstream to add these to EXTRA_DIST.
> >...
> 
> The ChangeLog file in the "source" tarball of the hello package is 
> generated from the git metadata.

How exciting.  So the official tarball of GNU hello is not the
preferred form for modification!

> You are saying it is a bug that .git is not shipped in the source 
> tarball of GNU hello?

Personally I think a Linux kernel tarball, without accompanying git
history, is a GPL violation.  But I don't expect to convince anyone...

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: Rebuilds with unexpected timestamps

[Holger Levsen]

On Tue, Nov 01, 2016 at 12:05:38PM +, Ian Jackson wrote:
> How exciting.  So the official tarball of GNU hello is not the
> preferred form for modification!

ironically I could say "welcome to 2016"… ;)

> Personally I think a Linux kernel tarball, without accompanying git
> history, is a GPL violation.  But I don't expect to convince anyone...
 
at least you got your expectations right ;)

to finally reply seriously: I think the sources themselves are still the
preferred form of modification, the git history is "just" another tool
to help one better understand the source, but it's absolutly not needed
to modify the source. This is comparable with eg. some configuration
files for an editor, which helps one to edit the source more easily, but
which in no way are needed to provide patches in the prefered form of
modifications.

And even if the prefered form for supplying a modification is a git
patch, thats easy to do with tarballs and git init…


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#842813: ITP: jsusfx -- Jesusonic FX - scripting language to audio DSP

[IOhannes m zmoelnig]

Package: wnpp
Severity: wishlist
Owner: IOhannes m zmoelnig 

* Package name: jsusfx
  Version : 0.3.1
  Upstream Author : Pascal Gauthier
* URL : https://github.com/asb2m10/jsusfx
* License : Apache2
  Programming Lang: C++
  Description : Jesusonic FX - scripting language to audio DSP

 jsusfx is an Open Source implementation of the JSFX scripting language that was
 created by Cockos and is made available with Reaper (a commercial multitrack
 editor and recorder).
 .
 This implementation is focusing on providing DSP scripting processing for other
 hosts (like Pure Data) and platforms.

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

Bug#842818: ITP: golang-github-btcsuite-fastsha256 -- Go fast SHA256 implementation

[Alessio Treglia]

Package: wnpp
Severity: wishlist
Owner: Alessio Treglia 

* Package name: golang-github-btcsuite-fastsha256
  Version : 0.0~git20160815.0.637e656
  Upstream Author : Btcsuite project
* URL : https://btcsuite.github.io/
* License : BSD-3-clause, ISC
  Programming Lang: Golang
  Description : Go fast SHA256 implementation

 This package provides an alternative fast-SHA256
 implementation to the one provided by the Go crypto/sha256
 package and supports midstate calculations.
 .
 This package is used by several Tendermint's components.

Multi-Arch: allowed

[Thibaut Paumard]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear all,

How do you actually use Multi-Arch: allowed? Should a dependent
package then specify either :same or :foreign? Looks
like it's not working:
https://piuparts.debian.org/sid/fail/gyoto-dbg_1.1.1-1.log

I was able to find documentation about what allowed is supposed to do,
but not on how to depend on such a package.
https://wiki.debian.org/Multiarch/HOWTO

Kind regards, Thibaut.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJYGJv5AAoJEJOUU0jg3ChA7d8P/j08FlvT0749AF3//fgR67q+
LIwQafiik8/jz2MSmLIX9U/N0cM8MwqemPsCWtSeHUbSb6/MRcI2uednDTuWEd8Q
rC4ySoa9Texk8ukyvrweQJxqmuUmXHl6/1Xh70Yp2jcFzN3Ngc1ipdtvaC6wlam5
GIhdLsHwBJLUih9dpKm8exVE3Y19V0TZqmaU1ZFUprDOlsPfJfQYY9py1VY4Lddc
21sTvNezelMzDAuZrapGfHUw5WqzEu9tmZbHZeARqb6kt/rUy3vEKr6KmY1iK+Qg
ia8wit1AVMu7Z8Y/ZjCvYgqKdHP5m0/qoWsGl7ioZo2aqKCupGYzLqyTjF/XB2aD
oQkzZ+k/oDNNKpiQ5uJMrfXatuMgvrtJIFFF5PJbbHC20X/n1GA0QH0z5BoSgYha
KcPFSIaTBlw6iBS7iv/6QpWXHh/c3fQgVD3hSHcPl8YOjYis2I3gxMj8At7wvZrT
3hmuRbinPxZxukO7HZrDH8qX/49N6YvBayuIkfSKGtGFKn4lt16zoawTUvnlNzud
JLRm+2dZylaft4/GLVmxn9mvO1iqQnTlsyAFfioxhdt080C1lJV6InsbFy1zhuH/
Brrc7PbfzlP6z5KjKRm+I56FcQT1ZOXr/SdGaWTdKqfksTdTjI8LM/jPpP0DhNuT
wkjLXwfufv6uO/H4NK4Z
=haeJ
-END PGP SIGNATURE-

Bug#842825: ITP: jupyter-console -- Jupyter terminal client

[Gordon Ball]

Package: wnpp
Severity: wishlist
Owner: Gordon Ball 

* Package name: jupyter-console
  Version : 5.0.0
  Upstream Author : Jupyter Development Team
* URL : https://github.com/jupyter/jupyter_console
* License : BSD
  Programming Lang: Python
  Description : Jupyter terminal client

This is the console interface for the jupyter interactive computing
environment (successor of IPython). Compared to the ipython terminal,
it supports language kernels other than python.

I will maintain this within the DPMT.

Re: Multi-Arch: allowed

[David Kalnischkies]

On Tue, Nov 01, 2016 at 02:43:21PM +0100, Thibaut Paumard wrote:
> How do you actually use Multi-Arch: allowed? Should a dependent
> package then specify either :same or :foreign? Looks

Neither is valid syntax.
What you do with these is depending on a package with the literal
architecture "same" (or "foreign"). Thats not going to work…


> I was able to find documentation about what allowed is supposed to do,
> but not on how to depend on such a package.
> https://wiki.debian.org/Multiarch/HOWTO

The spec [0] linked from that page says how, but in summary:
If a package (lets say perl) is marked as Multi-Arch: allowed your
package foo can depend on perl:any and a perl package from any (foreign)
architecture will statisfy this dependency, while a 'simple' perl would
have just accepted a perl from the architecture your package foo was
built for (with arch:all mapped to arch:native).

DO NOT use ":any" on a package which is NOT marked as Multi-Arch:
allowed [1]. This isn't satisfiable by ANYTHING, not even your native
package.

If it helps: Instead of "perl having Multi-Arch: allowed" envision it to
have a "perl provides perl:any" and you are depending on this virtual
package – which also explains why such a missing provides causes
perl:any to be unresolveable.


That said, the usecase for 'allowed' is small – mostly interpreters
– and you are trying to use it on… a -dbg package? I haven't looked
closely, but that smells wrong… What are you trying to express here?
(and have you heard that automatic debug packages are a thing nowadays?)


Best regards

David Kalnischkies

[0] https://wiki.ubuntu.com/MultiarchSpec
[1] There are ways around it. See the "If it helps" remark for a hint.


signature.asc
Description: PGP signature

Re: Rebuilds with unexpected timestamps

[Simon McVittie]

On Mon, 31 Oct 2016 at 17:02:53 +0200, Adrian Bunk wrote:
> The ChangeLog file in the "source" tarball of the hello package is 
> generated from the git metadata.
> 
> You are saying it is a bug that .git is not shipped in the source 
> tarball of GNU hello?

I don't think it is, but I also can't articulate very clearly why I
think that, given that I think omitting git-version-gen *is* a bug.

I think the best I can do is to point out that there is a large
qualitative difference between the build system and the ChangeLog.
The scripts that make up the build system are executable code that we
are expected to run (so we have to be able to trust that they aren't
doing anything malicious), and they do something with functional effects
(so they can have bugs that we have a practical need to fix).

A ChangeLog is a piece of non-executable text describing historical
events: sure, it can have bugs too (changes that are described
incorrectly, or insufficiently clearly, perhaps even in ways that
indirectly cause functional bugs), but in practice we are never going
to fix those bugs (and indeed if we were to consider git history to be
its preferred form for modification, then we *couldn't* fix those bugs
without rewriting history).

If you look at the packages that I maintain in contrib, you'll notice
that I clearly have no problem with non-Free games, particularly
ones with Free engines. I think there's a spectrum between purely
practical/functional engineering at one end, and purely aesthetic art at
the other end, with the vast majority of software somewhere in between
(and game engines considerably closer to the functional end of that
scale than game artwork/levels are). The further something is from the
purely functional end of that scale, the more I'm prepared to tolerate
it being non-Free (although I recognise that this doesn't necessarily
match Debian consensus). I suppose I'm applying similar logic to
"social" documents like changelogs and licensing information: they
are not a piece of practical, functional engineering in the same way
that executable code is, so I don't see a need for them to be treated
entirely equally.

I realise that the Debian Social Contract officially doesn't draw any
distinction between classes of software - that's why we insist that
documentation is just as Free as executable code. However, I also think
that if we try to formulate simple rules based on what is desirable for
executable, functional code - closer to the "engineering" end of my
scale than to the "art" end - and apply them mechanistically to all
software, there's a danger of spending a lot of effort and goodwill
on solving purely theoretical problems for the sake of consistency,
and in the worst case legislating ourselves into irrelevance. The most
obvious example is that if we insisted that license texts must themselves
be released under a Free license, we wouldn't be able to ship anything
GPL'd at all, and that's clearly unacceptable for a Linux distribution :-)

Back to changelogs and git history: while I would prefer to have
complete history available for most software that I plan to modify,
I don't think the absence of that history makes it non-free, and
it is clearly not the case that the authors of the GPL (whose term
"preferred form for modification" we frequently refer to as our best
working definition of source code) considered complete history to be a
necessary part of a source release. Looking at its git history, GNU Emacs
doesn't appear to have even been stored in RCS until 1994, 5 years after
"the preferred form of the work for making modifications to it" appeared
in the GPL version 1. I sometimes think that "*the* preferred form for
modication" is an unhelpful meme, and we should instead be thinking about
"*a* preferred form for modification", acknowledging that the preferred
form is not necessarily unique.

In any case, we are not going to have complete git history shipped in
Debian any time soon, because the ftp-masters have (IMO correctly)
refused to deploy source formats where the entire git history of a
project is uploaded to Debian: they rightly don't want to be responsible
for verifying that the entire history of a project is Free (and in many
cases it isn't).

S

Bug#842839: ITP: golang-github-golang-leveldb -- The LevelDB key-value database in the Go programming language.

[Sascha Steinbiss]

Package: wnpp
Severity: wishlist
Owner: Sascha Steinbiss 

* Package name: golang-github-golang-leveldb
  Version : 0.0~git20161002.0.64b1965-1
  Upstream Author : The LevelDB-Go Authors
* URL : https://github.com/golang/leveldb
* License : BSD-3-clause
  Programming Lang: Go
  Description : The LevelDB key-value database in the Go programming 
language.

This package is a Go version of the LevelDB lightweight key-value database.
It is provided as a dependency of stenographer 
(https://github.com/google/stenographer).

Re: Rebuilds with unexpected timestamps [and 1 more messages]

[Sean Whitton]

Hello,

On Tue, Nov 01, 2016 at 09:09:56AM +0800, Paul Wise wrote:
> That already exists (see the dpkg-source manual page), but IIRC isn't
> allowed in the archive because the ftp-masters do not want to have to
> analyse the whole history of a git repository for DFSG issues.

On Tue, Nov 01, 2016 at 07:34:02AM +0100, Adam Borowski wrote:
> Ie, we want the repositories pruned.  Git supports incomplete repositories
> just fine (aka shallow clones), although I'm not aware of existing tools
> that would shape the pruning of an existing repository.

What's needed is for git-bundle(1) to gain --shallow.

Anyone want to submit a patch upstream? :)

-- 
Sean Whitton

Re: Multi-Arch: allowed

[Thibaut Paumard]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear David,

Le 01/11/2016 à 15:57, David Kalnischkies a écrit :
> On Tue, Nov 01, 2016 at 02:43:21PM +0100, Thibaut Paumard wrote:
>> How do you actually use Multi-Arch: allowed? Should a dependent 
>> package then specify either :same or :foreign?
>> Looks
> 
> Neither is valid syntax. What you do with these is depending on a
> package with the literal architecture "same" (or "foreign"). Thats
> not going to work…
> 
> 
>> I was able to find documentation about what allowed is supposed
>> to do, but not on how to depend on such a package. 
>> https://wiki.debian.org/Multiarch/HOWTO
> 
> The spec [0] linked from that page says how, but in summary:

Thanks, I was not able to parse it correctly apparently.

> If a package (lets say perl) is marked as Multi-Arch: allowed your 
> package foo can depend on perl:any and a perl package from any
> (foreign) architecture will statisfy this dependency, while a
> 'simple' perl would have just accepted a perl from the architecture
> your package foo was built for (with arch:all mapped to
> arch:native).
> 
[...]
> If it helps: Instead of "perl having Multi-Arch: allowed" envision
> it to have a "perl provides perl:any" and you are depending on this
> virtual package – which also explains why such a missing provides
> causes perl:any to be unresolveable.

That makes things clearer, thanks.

> 
> That said, the usecase for 'allowed' is small – mostly
> interpreters – and you are trying to use it on… a -dbg package? I
> haven't looked closely, but that smells wrong… What are you trying
> to express here?

The -dbg package is Multi-Arch same. It Depends on the packages for
which it provides debugging symbols, some of which are Multi-Arch:
allowed. Lintian complains when I don't specify an architecture for
those packages:

W: gyoto source: dependency-is-not-multi-archified gyoto-dbg depends
on gyoto-bin (multi-arch: allowed)
N:
N:The package is Multi-Arch "same", but it depends on a package
that is
N:neither Multi-Arch "same" nor "foreign".
N:
N:Refer to https://wiki.ubuntu.com/MultiarchSpec for details.
N:
N:Severity: normal, Certainty: possible
N:
N:Check: group-checks, Type: source
N:


By the way, by the same logic that interpreters should (or can?) be
Multi-Arch: allowed, I expect that
  - extensions for those interpreters also should (or can?);
  - any tool that is able to process an input data file to produce a
arch-independent output also should (or can?) be either "foreign" or
"allowed".
Is that correct?

> (and have you heard that automatic debug packages are a thing
> nowadays?)

Yes. Last time I checked, it was not clear how to use them in
backports though.

> 
> 
> Best regards
> 
> David Kalnischkies
> 
> [0] https://wiki.ubuntu.com/MultiarchSpec [1] There are ways around
> it. See the "If it helps" remark for a hint.
> 

Kind regards, Thibaut.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJYGMy/AAoJEJOUU0jg3ChA+hwQAKh7C+MfqrTPAL8WPQeUVAQh
ZT6N2R2ugOmUBwW2wGtLvA1V6A6Nr9QME7Yjs9DVppd8kV5mWmOT1hJMyu+Wn0Hi
XNvDIKrH9R6vgdRRyIxZIeSFdedf8QUYmEPnP7hkE8oTazFcTe8LpZfB4Ju3Blbp
u+er1S7qSBei9ZEpsYKP13HA9G1C33Y7rTmgCgqm9sxuk7GmPiF5CKGR2JHS7kAZ
YVodtJOF7diiuKfP6XQdKNUCgjH7x9EHk8BZ9s4sNeOb+TpAPRlvhTdb4c30i32e
vGBUtP8VLRHH8IfxxrldmJecb8StHg+uE1+nM9jBFYRJ/hPAq1z22SeY1COMwyyd
JSBaCD24XBC+YGgOBfVTz8F7r6hkumuQoJhgcARhRCVkYPQ9hxYFnzgz1igcoSTt
tJ8YKgObWdItjC8MF9a1fayPwS7krAwKdB+/h4aZqft8fXPgc+d16b+8izjRvRhP
1WHp2GnG9Y3Tstvibge7AH13J2u/NxykZc3OyN/SdW1FBdMAEUuVvRGYPG+4ddqL
zycMWjmgy+5QS3ts246foT/4OSfG+30ooFct7ikLEnWajzd1u5IocB95/wUzgaKq
0+VNTj8tLUpWibIipNTxDHeVTRpGERzxJGqv20ztgtGSG6bX75gGrFncoev0ykox
n7sbt9I4/AUJbqvrFoWM
=UNTB
-END PGP SIGNATURE-

Re: Bug#842839: ITP: golang-github-golang-leveldb -- The LevelDB key-value database in the Go programming language.

[Martín Ferrari]

On 01/11/16 16:31, Sascha Steinbiss wrote:

> This package is a Go version of the LevelDB lightweight key-value database.
> It is provided as a dependency of stenographer 
> (https://github.com/google/stenographer).

According to the webpage, this package is unfinished and experimental.
You are probably better off using https://github.com/syndtr/goleveldb,
which is already packaged.

-- 
Martín Ferrari (Tincho)

Bug#842857: ITP: node-js-tokens -- Regex that tokenizes JavaScript

[Lucas Castro]

Package: wnpp
Severity: wishlist
Owner: Lucas Castro 

* Package name: node-js-tokens
  Version : 2.0.0
  Upstream Author : Simon Lydell <>
* URL : https://github.com/lydell/js-tokens/blob/master/readme.md
* License : MIT/X
  Description : Regex that tokenizes JavaScript


 js-tokens provides a regex with the g flag that matches JavaScript
 tokens.

Re: Rebuilds with unexpected timestamps

[Adrian Bunk]

On Tue, Nov 01, 2016 at 12:05:38PM +, Ian Jackson wrote:
>...
> Personally I think a Linux kernel tarball, without accompanying git
> history, is a GPL violation.
>...

Why would the git *history* matter for GPL compliance?

You can push from a shallow clone.

> Ian.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Lots and lots of tiny node.js packages

[Ian Jackson]

Sruthi Chandran writes ("Bug#840937: ITP: node-kind-of -- Get the native type 
of a value"):
> * URL : https://github.com/jonschlinkert/kind-of

Pirate Praveen writes ("Bug#842129: ITP: node-path-type -- Check if a path is a 
file, directory, or symlink"):
> * URL : https://github.com/sindresorhus/path-type#readme

I picked these two almost at random.

I appreciate you're working hard to package up all this web
application infrastructure.  This is an area that Debian is doing
rather poorly in and it is good to see efforts to improve it.

But:

These are tiny packages and there seem to be lots and lots and lots of
them.

Every new source package and binary package is (or causes):
 * An entry in Sources and Packages that everyone, even everyone
   who doesn't use it, needs to download
 * A database entry in each of our package management systems
   (the DAK db, the BTS, the PTS/tracker, buildds, etc.)
 * Processing overhead for every Debian system everywhere on
   the planet, while parsing packaging databases, representing
   package graphs
 * A mail like these ITPs
 * Human effort to review it separately in NEW, ITPs, sponsorship (if
   applicable), etc., which would be easier if aggregated
 * Corresponding edges in the Debian dependency graphs
 * Probably several separate git repositories

Our systems are not really set up for so many packages.  They were
designed with the assumption that a package would represent a
substantial amount of upstream work, so that the Debian overhead is
modest by comparison.

Can you explain why you don't aggregate these into bigger packages,
for use in Debian ?

I don't think it matters very much exactly what the aggregation
boundaries are but I think given the size of these packages when I
looked at a couple upstream, you could profitably put many dozens of
these tiny libraries into a single .dsc and .deb.

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: Static linking and fPIC (Was: Re: "PIE by default" transition is underway -- wiki needs updating)

[Adrian Bunk]

On Mon, Oct 31, 2016 at 03:23:51PM +0100, Bálint Réczey wrote:
> Hi Ian,
> 
> 2016-10-31 14:19 GMT+01:00 Ian Campbell :
> > On Mon, 2016-10-31 at 12:17 +0100, Bálint Réczey wrote:
> >> 2016-10-31 10:38 GMT+01:00 Ian Campbell :
> >> > If possible I'd also prefer a solution which fixed qcontrol-static
> >> > without opting out for the normal dynamic/non-udeb binary.
> >>
> >> I ran the build tests on amd64, this is why I have not caught this error.
> >> A rebuild of lua5.1 should fix the problem.
> >>
> >> Dpkg changes are on their way, too in the next days. I would ask
> >> for a binNMU after dpkg is updated.
> >
> > Thanks, to check I understand: I should wait for #835146 to be fixed in
> > sid (which is expected to happen via a dpkg upload in the next days)
> > and then ask for a binNMU of lua5.1 then qcontrol (or maybe I have
> > reason to upload a newer qcontrol anyway, we'll see)?
> 
> Yes, this should fix qcontrol and maybe you don't even have to ask for
> rebuilds.  I think there is already an archive-wide rebuild planned to
> make reproducibility-related changes in dpkg take effect thus I suggest
> waiting a few days to see if you need to ask for binNMUs.

I do not see any reason for waiting instead of sending the binNMU 
request right now.

Based on the error message the only problem for qcontrol is that the
LUA 5.1 static library has not been compiled with the toolchain that
defaults to PIE, and the one and only change required to fix the build
of qcontrol should therefore be to request a binNMU of lua5.1

> Cheers,
> Balint

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: Multi-Arch: allowed

[Simon McVittie]

On Tue, 01 Nov 2016 at 18:11:27 +0100, Thibaut Paumard wrote:
> The -dbg package is Multi-Arch same. It Depends on the packages for
> which it provides debugging symbols, some of which are Multi-Arch:
> allowed. Lintian complains when I don't specify an architecture for
> those packages:
> 
> W: gyoto source: dependency-is-not-multi-archified gyoto-dbg depends
> on gyoto-bin (multi-arch: allowed)
> N:
> N:The package is Multi-Arch "same", but it depends on a package
> that is
> N:neither Multi-Arch "same" nor "foreign".

It is not useful for gyoto-dbg to be Multi-Arch: same as long as it
Depends on gyoto-bin.

Imagine you want to be able to debug gyoto i386 and amd64 libraries,
or some other pair of architectures, at the same time (which is the
reason why Multi-Arch: same debug symbols are useful). You install
libgyoto0:amd64 and libgyoto0:i386 (or whatever the SONAME is); fine.
Next you install gyoto-dbg:amd64, which pulls in gyoto-bin:amd64; still
fine so far. Finally, you try to install gyoto-dbg:i386, but it Depends
on gyoto-bin:i386, which is not co-installable with gyoto-bin:amd64,
so you can't.

You can either:

* stop generating gyoto-dbg, and get the automatic debug packages
  (but they won't be made available in jessie-backports)

* remove the Multi-Arch field from gyoto-dbg

* weaken its Depends on gyoto-bin to a Recommends or something

Regards,
S

Re: Lots and lots of tiny node.js packages

[Guus Sliepen]

On Tue, Nov 01, 2016 at 08:50:38PM +, Ian Jackson wrote:

> These are tiny packages and there seem to be lots and lots and lots of
> them.

I agree, but I'll play the devil's advocate here for a while:

> Every new source package and binary package is (or causes):
>  * An entry in Sources and Packages that everyone, even everyone
>who doesn't use it, needs to download

Apt downloads diffs nowadays, so apart from the first download, updates
are much smaller.

>  * A database entry in each of our package management systems
>(the DAK db, the BTS, the PTS/tracker, buildds, etc.)

While there are a lot of node.js packages, it doesn't look to me like
we're packaging more of those than of other packages. If this is too
much for Debian, it means we are already at a limit. Are we really?

>  * Processing overhead for every Debian system everywhere on
>the planet, while parsing packaging databases, representing
>package graphs

Same as above.

>  * Human effort to review it separately in NEW, ITPs, sponsorship (if
>applicable), etc., which would be easier if aggregated

Really? The nice thing about these packages is that they are small and
mostly have singular, well-defined functions that make them much easier
to review than an aggregated bundle.

>  * Corresponding edges in the Debian dependency graphs

See above.

>  * Probably several separate git repositories

Again, are we at some limit?

> Our systems are not really set up for so many packages.

People keep saying this over and over but I haven't seen any proof that
Debian is falling apart just from the number of packages it supports. Is
this just something that we say to ratify our desire to block small
packages, or are there numbers to back this up?

> Can you explain why you don't aggregate these into bigger packages,
> for use in Debian ?

Because upstream doesn't aggregate them, and the hole point of the
node.js stuff is apparantly that you can mix&match a lot of small
packages without pulling in useless dependencies.

> I don't think it matters very much exactly what the aggregation
> boundaries are but I think given the size of these packages when I
> looked at a couple upstream, you could profitably put many dozens of
> these tiny libraries into a single .dsc and .deb.

You say the exact boundary doesn't matter but you don't agree with the
boundary currently being chosen. That's not very helpful. Is there a
minimum package size we should have? And why not then just require to
package all of node.js into one big package?

- End of devil's advocate talk -

I agree that it looks like these node.js packages do not map well to
what we in Debian traditionally think of as packages. But that's more
because most other languages out there have decent standard libraries,
and if there are things that are not supported by those, we have
libraries that comprehensively cover certain topics. I think ultimately,
the node.js ecosystem will face some serious problems when they will
also start to feel the pain of exploding dependency graphs, especially
when they will have multiple versions of packages with different
A[BP]Is.

They already have the serious problem that you need to download so many
dependencies just to get something working, that they have to work
around that by distributing "browserified" amalgations of their
dependencies just to make things easy for users.

But still, there is DFSG-complaint software out there that is built with
this stuff and that people clearly want in Debian. Geting that in
Debian's main section seems like the proper thing to do. The pain (real
or imagined) that it's causing should be a learning experience, and I
hope that the node.js community will also draw lessons from it.
Already I've seen that just the ITPs are causing people to review the
packages and finding bugs in them.

Creating larger packages that aggregate multiple node.js packages seems
like a nice idea to bring some order into the chaos (and perhaps reduce
the load on our resources). But seriously, how do we draw the
boundaries? Given the huge number of node.js packages, is there a way to
automate this? How much churn is there and how often do we need to
update those packages? What if node.js package A depends on C version 1,
and package B depends on C version 2, how do we package that in Debian?
It's relatively easy when C is its own package in Debian, then just
create C1 and C2 (like we do with libraries with sonames), but what if C
is in a much larger aggregate package?

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: Digital signature

Re: OpenSSL 1.1.0

[Cyril Brulebois]

Hi,

Just random thoughts…

Kurt Roeckx  (2016-11-01):
> 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.
> 
> The changes required are ussually very easy and do not take a long
> time to implement.
> 
> Many upstream projects have already done the work or are working
> on it. Fedora is also doing the OpenSSL 1.1.0 migration. So both
> places are a good place to look at to see if they have already
> done the work.
> 
> There might also be packages for which the changes are more
> involved and that can't be fixed in time for the release. If you
> want to stay with OpenSSL 1.0.2 you need to change your Build-Depends
> from libssl-dev to libssl1.0-dev.
> 
> I would like to encourage that at least the packages that are
> making use of libssl and not just libcrypto move to OpenSSL 1.1.0
> because it contains important new features. It adds support for
> among other things of:
> - Extended master secret: This fixes the triple handshake problem
>   in TLS.
> - Chacha20-poly1305
> - X25519

Things that work fine for this kind of transitions (hello, new gcc
upstream releases) include:
 - pointers to upstream release notes;
 - pointers to porting guides;
 - pointers to existing patches for common fixes if the former don't
   exist just yet (but then that would be a rather unprepared move).

(Mentioning “many upstream projects” and “Fedora” is better than nothing
but isn't as helpful as what I've listed above.)

> If you have any problems feel free to contact us.

 - are “you” ?


KiBi.


signature.asc
Description: Digital signature

Re: Lots and lots of tiny node.js packages

[Eric Cooper]

I see that a similarly large number of smallish libraries are getting
packaged for golang.  When I first looked into it, and maybe it's
still the case, these were only to allow other Debian packages written
in Go to be compiled; developers were still encouraged to use the Go
package ecosystem ("go get ...").  And whenever I've built node
programs, I also just use "npm install ..." rather than looking for a
Debian package.

If that's the primary use case, then perhaps there could be a simpler
way to deal with the dependencies of node and Go projects than
packaging each of them for a mostly nonexistent developer audience.
We could just make snapshots of the versions (obtained via "go get" or
"npm install") used to build the end-user packages, for
auditing/security/reproducibility purposes. These could be stored in a
well-defined place in the Debian archives, without "exporting" them
via .deb files, Packages entries, etc.

--
Eric Cooper e c c @ c m u . e d u

Re: OpenSSL 1.1.0

[Kurt Roeckx]

On Tue, Nov 01, 2016 at 11:26:15PM +0100, Cyril Brulebois wrote:
> Hi,
> 
> Just random thoughts…
> 
> Kurt Roeckx  (2016-11-01):
> > 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.
> > 
> > The changes required are ussually very easy and do not take a long
> > time to implement.
> > 
> > Many upstream projects have already done the work or are working
> > on it. Fedora is also doing the OpenSSL 1.1.0 migration. So both
> > places are a good place to look at to see if they have already
> > done the work.
> > 
> > There might also be packages for which the changes are more
> > involved and that can't be fixed in time for the release. If you
> > want to stay with OpenSSL 1.0.2 you need to change your Build-Depends
> > from libssl-dev to libssl1.0-dev.
> > 
> > I would like to encourage that at least the packages that are
> > making use of libssl and not just libcrypto move to OpenSSL 1.1.0
> > because it contains important new features. It adds support for
> > among other things of:
> > - Extended master secret: This fixes the triple handshake problem
> >   in TLS.
> > - Chacha20-poly1305
> > - X25519
> 
> Things that work fine for this kind of transitions (hello, new gcc
> upstream releases) include:
>  - pointers to upstream release notes;
>  - pointers to porting guides;

All the filed bugs already contain a link to the porting guide.

>  - pointers to existing patches for common fixes if the former don't
>exist just yet (but then that would be a rather unprepared move).
> 
> (Mentioning “many upstream projects” and “Fedora” is better than nothing
> but isn't as helpful as what I've listed above.)
> 
> > If you have any problems feel free to contact us.
> 
>  - are “you” ?

Yes.


Kurt

Re: OpenSSL 1.1.0

[Kurt Roeckx]

On Tue, Nov 01, 2016 at 11:49:52PM +0100, Kurt Roeckx wrote:
> > > If you have any problems feel free to contact us.
> > 
> >  - are “you” ?
> 
> Yes.

or openssl-us...@openssl.org


Kurt

Bug#842870: ITP: zodbpickle -- Fork of pickle module, for ZODB

[Julien Muchembled]

Package: wnpp
Severity: wishlist
Owner: Julien Muchembled 

* Package name: zodbpickle
  Version : 0.7.0~1.gc9e09e3-1
  Upstream Author : Zope Foundation and Contributors 
* URL : https://github.com/zopefoundation/zodbpickle
* License : Python, Zope-2.1
  Programming Lang: Python
  Description : Fork of pickle module, for ZODB

 This package presents a uniform pickling interface for ZODB:
 .
 Under Python 2, this package forks both Python 2.7’s pickle and cPickle
 modules, adding support for the protocol 3 opcodes. It also provides a new
 subclass of bytes, zodbpickle.binary, which Python2 applications can use to
 pickle binary values such that they will be unpickled as bytes under Python 3.
 .
 Under Python 3, this package forks the pickle module (and the supporting C
 extension) from both Python 3.2 and Python 3.3. The fork adds support for the
 noload operations used by ZODB.

This is a required dependency for the new version of ZODB, and I plan to
maintain it as part of the Debian Python Modules Team. See also

 
https://lists.debian.org/msgid-search/8e7791a6-97fd-6a68-8bc2-dee31266c...@jmuchemb.eu

Re: Lots and lots of tiny node.js packages

[Marco d'Itri]

On Nov 01, Ian Jackson  wrote:

> Can you explain why you don't aggregate these into bigger packages,
> for use in Debian ?
Because the node.js ecosystem is toxic and broken in encouraging 
relasing software which embeds very specific versions of lots of tiny 
libraries, and because Debian is ideologically against duplicating code 
in different packages and build systems downloading code ad built time.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#842874: ITP: python-btrees -- scalable persistent object containers for Python

[Julien Muchembled]

Package: wnpp
Severity: wishlist
Owner: Julien Muchembled 

* Package name: python-btrees
  Version : 4.3.1-1
  Upstream Author : Zope Foundation and Contributors 
* URL : https://github.com/zopefoundation/BTrees
* License : Zope-2.1
  Programming Lang: Python
  Description : scalable persistent object containers for Python

 This package contains a set of persistent object containers built around a
 modified BTree data structure. The trees are optimized for use inside ZODB's
 “optimistic concurrency” paradigm, and include explicit resolution of
 conflicts detected by that mechanism.

This is a required dependency for the new version of ZODB, and I plan to
maintain it as part of the Debian Python Modules Team. See also

 
https://lists.debian.org/msgid-search/8e7791a6-97fd-6a68-8bc2-dee31266c...@jmuchemb.eu

Re: NRSS has been deprecated [#696302]

[Adrian Bunk]

On Sun, Oct 30, 2016 at 06:28:41AM +0100, Adam Borowski wrote:
>...
> An user interested in future releases is usually a contributor of sorts,
> thus often has "devscripts" installed.

The typical user of Debian stable is running Debian on servers,
and will become interested in a future release after it became stable.

>...
> Once stretch is released, we'd file thousands of ITRs, listen to the
> crickets for a bit, then greatly decruft the archive!
>...

If you want to reduce the amount of cruft in the archive,
you should look at the other end.

When something that was ITP'ed into Debian is declared cruft after it 
has been shipped in stable releases, the question should be why it was 
allowed into Debian in the first place.

Especially when looking at the quality of much of the stuff from GitHub, 
the 10k binary packages that are new in stretch should be a bigger worry
than packages with a history of not causing problems in past releases.

> (although if popcon is 4 or so, that's probably telling enough).

It is telling us that relying on popcon numbers for anything is harmful.

What popcon numbers do you expect for architecture-specific packages 
that are only relevant for a subset of the supported hardware on a port?

Half of the stretch release architectures have a popcon lower than 25.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#842876: ITP: zc.customdoctests -- Use Python doctest with other languages

[Julien Muchembled]

Package: wnpp
Severity: wishlist
Owner: Julien Muchembled 

* Package name: zc.customdoctests
  Version : 1.0.1+1.gc142624-1
  Upstream Author : Zope Foundation and Contributors 
* URL : https://github.com/zopefoundation/zc.customdoctests
* License : Zope-2.1
  Programming Lang: Python
  Description : Use Python doctest with other languages

 doctest (and recently manuel) provide hooks for using custom doctest
 parsers. zc.customdoctests helps to leverage this to support other
 languages, such as JavaScript (with python-spidermonkey):
 .
 js> function double (x) {
 ... return x*2;
 ... }
 js> double(2)
 4
 .
 And with python-manuel, it facilitates doctests that mix multiple languages,
 such as Python, JavaScript, and sh.

This is a required dependency for the new version of ZODB, and I plan to
maintain it as part of the Debian Python Modules Team. See also

 
https://lists.debian.org/msgid-search/8e7791a6-97fd-6a68-8bc2-dee31266c...@jmuchemb.eu

Re: NRSS has been deprecated [#696302]

[Holger Levsen]

On Wed, Nov 02, 2016 at 01:08:44AM +0200, Adrian Bunk wrote:
> > An user interested in future releases is usually…
> The typical user of Debian stable is…

*the* typical Debian user does not exist.


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Re: Multi-Arch: allowed

[David Kalnischkies]

On Tue, Nov 01, 2016 at 09:24:10PM +, Simon McVittie wrote:
> On Tue, 01 Nov 2016 at 18:11:27 +0100, Thibaut Paumard wrote:
> > The -dbg package is Multi-Arch same. It Depends on the packages for
> > which it provides debugging symbols, some of which are Multi-Arch:
> > allowed. Lintian complains when I don't specify an architecture for
> > those packages:
> > 
> > W: gyoto source: dependency-is-not-multi-archified gyoto-dbg depends
> > on gyoto-bin (multi-arch: allowed)
> > N:
> > N:The package is Multi-Arch "same", but it depends on a package
> > that is
> > N:neither Multi-Arch "same" nor "foreign".
> 
> It is not useful for gyoto-dbg to be Multi-Arch: same as long as it
> Depends on gyoto-bin.
> 
> Imagine you want to be able to debug gyoto i386 and amd64 libraries,
> or some other pair of architectures, at the same time (which is the
> reason why Multi-Arch: same debug symbols are useful). You install
> libgyoto0:amd64 and libgyoto0:i386 (or whatever the SONAME is); fine.
> Next you install gyoto-dbg:amd64, which pulls in gyoto-bin:amd64; still
> fine so far. Finally, you try to install gyoto-dbg:i386, but it Depends
> on gyoto-bin:i386, which is not co-installable with gyoto-bin:amd64,
> so you can't.
> 
> You can either:
> 
> * stop generating gyoto-dbg, and get the automatic debug packages
>   (but they won't be made available in jessie-backports)
> 
> * remove the Multi-Arch field from gyoto-dbg
> 
> * weaken its Depends on gyoto-bin to a Recommends or something

I would add:

* Check if gyoto-bin really needs to be M-A:allowed. Name, Description
and the list of filenames included in the package suggest to me that the
package can and should be M-A:foreign – or in other words: Why is it
allowed?

* otherwise: Check if gyoto-bin can't be split up into a package which
can be marked M-A:foreign and one which can be marked M-A:same.


Rule of thumb: Don't make any package M-A:allowed as long as you haven't
got a bugreport telling you it would be nice from some cross-folks (be
it grader, builder, bootstrapper, …). Reason is that M-A:same/foreign is
instantly useable/ful, but M-A:allowed is useless if nothing ends up
depending on it with :any.


Best regards

David Kalnischkies


signature.asc
Description: PGP signature

Re: Lots and lots of tiny node.js packages

[Jonas Smedegaard]

Quoting Eric Cooper (2016-11-01 23:24:48)
> I see that a similarly large number of smallish libraries are getting 
> packaged for golang.  When I first looked into it, and maybe it's 
> still the case, these were only to allow other Debian packages written 
> in Go to be compiled; developers were still encouraged to use the Go 
> package ecosystem ("go get ...").  And whenever I've built node 
> programs, I also just use "npm install ..." rather than looking for a 
> Debian package.
> 
> If that's the primary use case,

It isn't.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: Lots and lots of tiny node.js packages

[Russ Allbery]

Ian Jackson  writes:

> Our systems are not really set up for so many packages.  They were
> designed with the assumption that a package would represent a
> substantial amount of upstream work, so that the Debian overhead is
> modest by comparison.

> Can you explain why you don't aggregate these into bigger packages,
> for use in Debian ?

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.

While it's true that our infrastructure doesn't scale ideally with lots of
small packages, it's also true that it is HORRIBLE at handling packages
that correspond to multiple independent upstream releases.  There is a bit
of multi-tarball support, but it's mostly useful for single packages that
upstream releases in separate tarballs for some bizarre reason of their
own, but still mostly in lockstep.  It doesn't deal at all well with lots
of entirely independent packages with their own version numbers and their
own release schedules.

Furthermore, this is horribly confusing for our users, who can't find the
Debian package that corresponds to the thing they want easily, get
confused by the mapping, can't find the version number of the thing they
care about, and otherwise get lots in this aggregation.  Understandably,
since it's weird and unusual.

If upstream themselves aggregates, then this works well.  (See, for
instance, TeX Live, which is basically an upstream aggregation of
independently-released packages.)  That gets its own version number and
its own unique existence and someone else is doing integration and release
management upstream of us and we can reuse some of their work.

But if we were going to do that, I think we would almost have to run a
separate TeX-Live-style project as an artificial upstream for Debian
packaging and do all the work that the TeX Live folks do to assemble that
distribution.  And that's even *more* work than the Node packagers are
already putting in, of somewhat dubious benefit (since it would only be to
reduce package metadata).

While it's true there are worries about scaling the archive to lots more
packages, I personally think the right path forward would be to fix things
that break in the archive to cope with this rather than to try to do
artificial bundling.  I think people seriously underestimate just how hard
the artificial bundling is both technically and in all of the user
interface issues it creates for our users.

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

Re: Lots and lots of tiny node.js packages

[Paul Wise]

On Wed, Nov 2, 2016 at 9:04 AM, Russ Allbery wrote:

> If upstream themselves aggregates, then this works well.  (See, for
> instance, TeX Live, which is basically an upstream aggregation of
> independently-released packages.)  That gets its own version number and
> its own unique existence and someone else is doing integration and release
> management upstream of us and we can reuse some of their work.
>
> But if we were going to do that, I think we would almost have to run a
> separate TeX-Live-style project as an artificial upstream for Debian
> packaging and do all the work that the TeX Live folks do to assemble that
> distribution.  And that's even *more* work than the Node packagers are
> already putting in, of somewhat dubious benefit (since it would only be to
> reduce package metadata).

Personally I think that even upstream aggregation on the scale of
XFree86 or TeX Live is annoying and I prefer the more fine-grained
packaging of Xorg, GNOME etc.

The web ecosystem is still changing rapidly, with WebAssembly coming
soon, so probably things are going to look very different for the
Debian buster development cycle.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Lots and lots of tiny node.js packages

[Pirate Praveen]

On 2016, നവംബർ 2 4:34:27 AM IST, m...@linux.it wrote:
>On Nov 01, Ian Jackson  wrote:
>
>> Can you explain why you don't aggregate these into bigger packages,
>> for use in Debian ?
>Because the node.js ecosystem is toxic and broken in encouraging 
>relasing software which embeds very specific versions of lots of tiny 
>libraries, and because Debian is ideologically against duplicating code
>
>in different packages and build systems downloading code ad built time.

In addition, that is more work (combined upstream maintenance, maintain patches 
for depended modules) combining these modules. I don't see the benefits 
outweigh the efforts. But if someone volunteers to do that work, that is 
welcome. Basically, the person doing the work has to become an upstream for the 
combined package. Currently, the number is high, but process is mostly 
automated and less error prone, this suggestion will make it manual, needing 
javascript knowledge, more error prone and no upstream support.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Crowd funding campaign to package browserify in debian

[Pirate Praveen]

On 2016, നവംബർ 2 2:22:00 AM IST, Bastien ROUCARIES 
 wrote:
>Did you means that you plan a rebuild of package with grunt when grunt
>is released ?

At the minimum the packages I care about and currently in contrib or should be 
in contrib. libjs-handlebars, libjs-fuzzaldrin-plus, jquery modules for pagure. 
It becomes easy for others to do the same.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Lots and lots of tiny node.js packages

[Russ Allbery]

Paul Wise  writes:
> On Wed, Nov 2, 2016 at 9:04 AM, Russ Allbery wrote:

>> If upstream themselves aggregates, then this works well.  (See, for
>> instance, TeX Live, which is basically an upstream aggregation of
>> independently-released packages.)  That gets its own version number and
>> its own unique existence and someone else is doing integration and
>> release management upstream of us and we can reuse some of their work.

>> But if we were going to do that, I think we would almost have to run a
>> separate TeX-Live-style project as an artificial upstream for Debian
>> packaging and do all the work that the TeX Live folks do to assemble
>> that distribution.  And that's even *more* work than the Node packagers
>> are already putting in, of somewhat dubious benefit (since it would
>> only be to reduce package metadata).

> Personally I think that even upstream aggregation on the scale of
> XFree86 or TeX Live is annoying and I prefer the more fine-grained
> packaging of Xorg, GNOME etc.

Yeah, I think it was a huge win all around when X upstream got rid of the
monolithic tree and packaged all of the components separately.

TeX Live works well, but that's partly because TeX is quite stable.

> The web ecosystem is still changing rapidly, with WebAssembly coming
> soon, so probably things are going to look very different for the
> Debian buster development cycle.

Indeed.

I do think the Node community takes this too far, with way too many
micropackages that should just be part of the standard library.  But,
well, it works for them, and it's not a totally unreasonable way to handle
things.  I think Debian should find ways to stay flexible and adjust and
incorporate those sorts of philosophies about the reusable unit of code.

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

Bug#842889: ITP: read-pkg -- Read a package.json file

[Sruthi Chandran]

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

* Package name: node-read-pkg
  Version : 2.0.0
  Upstream Author : Sindre Sorhus 
(sindresorhus.com)
* URL : https://github.com/sindresorhus/read-pkg#readme
* License : Expat
  Programming Lang: JavaScript
  Description : Read a package.json file

Bug#842894: ITP: node-regenerator-runtime -- Runtime for Regenerator-compiled generator and async functions

[Sruthi Chandran]

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

* Package name: node-regenerator-runtime
  Version : 0.9.5
  Upstream Author : Ben Newman 
* URL : FIX_ME homepage
* License : Expat
  Programming Lang: JavaScript
  Description : Runtime for Regenerator-compiled generator and async
functions