Bug#842231: ITP: node-spdx-correct -- correct invalid SPDX identifiers

[Sruthi Chandran]

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

* Package name: node-spdx-correct
  Version : 1.0.2
  Upstream Author : Kyle E. Mitchell 
(https://kemitchell.com)
* URL : https://github.com/kemitchell/spdx-correct.js#readme
* License : Apache-2.0
  Programming Lang: JavaScript
  Description : correct invalid SPDX identifiers

Re: Planned NMU of w3-recs would use much archive disk space

[Marco d'Itri]

On Oct 27, "Thaddeus H. Black"  wrote:

> Unfortunately, without an NMU, this package would not be very
> useful to stretch users.
> 
> I'd do what I could to trim the size, but this NMU will be big
> no matter what I do.
> 
> Advice?  Objections?
What is the purpose of this package?

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: Bug#842191: ITP: node-is-fullwidth-code-point -- Check if the character represented by a given Unicode code point is fullwidth

[Pirate Praveen]

On Thursday 27 October 2016 12:09 PM, Adam Borowski wrote:
> On Thu, Oct 27, 2016 at 10:00:37AM +0530, Pirate Praveen wrote:
>> On Thursday 27 October 2016 02:21 AM, Adam Borowski wrote:
>>> On Thu, Oct 27, 2016 at 12:49:31AM +0530, suhail_p wrote:
 * Package name: node-is-fullwidth-code-point
   Upstream Author : Sindre Sorhus  
 (sindresorhus.com
 )
 * URL :
 https://github.com/sindresorhus/is-fullwidth-code-point#readme
   Description : Check if a given Unicode point is fullwidth

  A Nodejs modeule to check if the character represented by a given Unicode
 code point is fullwidth
>>>
>>> Wouldn't it be better to replace this with full wcwidth()?  That'd give you
>>> not only double-width chars but also controls ("width" -1), combining and
>>> non-spacing (width 0).
>>
>> It is a dependency for https://github.com/sindresorhus/string-width you
>> can suggest upstream to use this.
> 
> Well, but why would you use code that's so buggy?  If it has literally one
> job, it should at least do that job right.
> 
> I see string-width ignores controls (0..0x1f, 0x7f..0x9f) on its own, so
> that's handled.  It reacts to them differently than POSIX wcswidth()
> (silently ignores instead of returning an error for the whole string) but
> as there's no good answer that's acceptable.
> 
> But, without having a case for width 0, string-width fails to handle any
> non-spacing or combining characters.  The former happen quite often in text
> produced by some software, sometimes even in surprising cases as plain
> German words like "Auflage" -- without a ZWNJ between f and l they'd be
> combined into a ligature.  The latter are required for a number of
> languages, such as Vietnamese which tends to decorate every letter with two
> or more combining characters.
> 
> Thus, I recommend scrapping this ITP, and instead packaging one of many
> implementations without these problems.  One for these that looks rightish
> is https://github.com/mycoboco/wcwidth.js
> 
> You would then patch string-width:
> - if (isFullwidthCodePoint(code)) {
> - width += 2;
> - } else {
> - width++;
> - }
> + width += wcwidth(code);
> 

Thanks for the patch, we'll do it as you suggest.



signature.asc
Description: OpenPGP digital signature

Bug#842241: ITP: node-regex-not -- Create a javascript regular expression for matching everything except for the given string

[Pirate Praveen]

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

* Package name: node-regex-not
  Version : 1.0.0
  Upstream Author : Jon Schlinkert (https://github.com/jonschlinkert)
* URL : https://github.com/jonschlinkert/regex-not
* License : Expat
  Programming Lang: JavaScript
  Description : Create a javascript regular expression for matching
everything except for the given string.



signature.asc
Description: OpenPGP digital signature

Re: Planned NMU of w3-recs would use much archive disk space

[Henrique de Moraes Holschuh]

On Thu, 27 Oct 2016, Marco d'Itri wrote:
> On Oct 27, "Thaddeus H. Black"  wrote:
> > Unfortunately, without an NMU, this package would not be very
> > useful to stretch users.
> > 
> > I'd do what I could to trim the size, but this NMU will be big
> > no matter what I do.
> > 
> > Advice?  Objections?
> What is the purpose of this package?

Offline/local reference with all W3C standards in the "Recommended"
status.  Basically, the same locus as the packages with the IETF
standards and RFCs.

It is also (IMHO) far more useful than some of the monster packages we
already have in the archive, so I'd say go ahead even if it is 200GiB.
So I vote for "do it".

That said, Thaddeus, if you do go ahead with the upload please check if
you can minimize that size somehow, even just a 10% drop in size would
already be worth the work it took for something big like this.

For example, suppose it ships the recommendations in several rendered
formats (PDF, PS, HTML/XHTML) and master hypertext (XML DOCBOOK,
whatever).  It would be quite acceptable to drop everything but the
xhtml/html+css+images versions from the binary packages: people won't
install these to print, they will install them to read while working on
something (code, documents, etc) or researching, and browser-friendly
hypertext is MUCH better for search, cut-and-paste, reading, and
alternative renderings (voiced, etc) than PDF/PS/etc.

-- 
  Henrique Holschuh

openssl transition

[Jörg Frings-Fürst]

Hello,

I have read the discussion about the openssl transition here again. 

One of the last notes was to be used openssl 1.0 and 1.1 in parallel
because of the non-trivial changes.

So I have some questions:

- The parallel use of release 1.0 and 1.1 will not be pursued?

- Why is the transition started with 0 (zero) good packages (from 552)?

- Should it be safer to switch to a new API at short notice and
under  pressure? 


CU
Jörg
-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser

Threema: SYR8SJXB

IRC: j_...@freenode.net
 j_...@oftc.net

My wish list: 
 - Please send me a picture from the nature at your home.


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

Re: When should we https our mirrors?

[Russell Stuart]

On Thu, 2016-10-27 at 08:35 +0200, Vincent Bernat wrote:
> Moreover, the download speed can be very slow, either from work or
> from home (100M fiber connection). Sometimes 100kbytes/s. That's a
> pain.
> 
> I am a bit worried for deb.debian.org to become a default as it
> doesn't work well for me. Am I alone to have such problems?

It's *far* better than httpredir.  But given adding httpredir as a
backup has become a net negative for me, that's not saying much. 
deb.debian.org so far has been net positive.

Yes, it's slow.  But for those of us who live on the east cost of
Australia our choices are ftp.au.debian.org (rock solid but 5Mm away,
connected to the east by wet string or carrier pigeon - pabs will
advise) or an Eastern mirror (fast but unpredictable and unreliable,
possibly because pabs doesn't live here[0]) it's the reason we need a
backup.  I was hoping for better given fastly has POP's in Australia,
but apparently the nearest fastly POP for Debian is in the US.

The real problem is mirroring infrastructure for Debian badly needs
some love.  As Raphael spelt out when explaining the current state of
httpredir - the problem lies deeper than httpredir itself. 
deb.debian.org can bypass most the mess because they control both ends
- debian and the "mirror".

I'm sure Debian is riddled with people who could fix the mirror
network.  In the usual Debian way (why does heart bleed spring to
mind?) it will become an impossible to ignore itch before one of us
gets off our fat arses to does something about it. [1]



[0] pure speculation.

[1] Antarctic penguins spring to mind.  All hungry, all standing on the
ice starring at the sea wondering if there are leopard seals waiting
for dinner to deliver itself, all hoping someone else will be hungry
enough to be the test the dinner theory before them. 

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

Bug#842243: ITP: node-defaults -- merge single level defaults over a config object

[suhail_p]

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

* Package name: node-defaults
  Version : 1.0.3
  Upstream Author : Elijah Insua 
* URL : https://github.com/tmpvar/defaults#readme
* License : Expat
  Programming Lang: JavaScript
  Description : merge single level defaults over a config object

 A simple one level options merge utility. This module
exports

 a function that takes 2 arguments: options and defaults.
 When called, it overrides all of undefined properties in
 options with the clones of properties defined in defaults.
 Sidecases: if called with a falsy options value, options will
 be initialized to a new object before being merged onto.
 .
 Node.js is an event-based server-side JavaScript engine.

Bug#842245: ITP: node-fs-exists-sync -- Drop-in replacement for `fs.existsSync` with zero dependencies

[Sarath M S]

Package: wnpp
Severity: wishlist
Owner: Sarath M S 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: node-fs-exists-sync
  Version : 0.1.0
  Upstream Author : Jon Schlinkert (https://github.com/jonschlinkert)
* URL : https://github.com/jonschlinkert/fs-exists-sync
* License : Expat
  Programming Lang: JavaScript
  Description : Drop-in replacement for Node.js's `fs.existsSync`
with zero dependencies.

 fs-exists-sync is a drop-in replacement for Node.js's `fs.existsSync`
with no dependencies. Other libraries have crucial differences from
fs.existsSync, or unnecessary dependencies.
 .
 Node.js is an event-based server-side JavaScript engine.




signature.asc
Description: OpenPGP digital signature

Re: Planned NMU of w3-recs would use much archive disk space

[Thaddeus H. Black]

This reply responds to the messages of Marco d'Itri
and Paul Wise.  Summary:  the package w3-recs provides
the standards by which web pages are developed; its
compressed source would be about 200 MiB in size.

On Thu, Oct 27, 2016 at 09:50:28AM +0200, Marco d'Itri wrote:
> What is the purpose of this package?

HTML, CSS, DOM, SVG, etc., are the standards according to which
web pages are developed (which you probably already knew, but I
explain it for the benefit of other readers).  Without content
developed according to these standards, Iceweasel/Firefox and
others would not be very useful.  This package provides the
standards for offline use.

If you were a web developer (I am not, except
incidentally) and online access to the standards is not
always convenient, then this package might interest you.
The package is thus similar in purpose to Iustin Pop's
package doc-rfc.

For information, the package has been in the archive
since 2002.  Its past (not present) maintainers
include Francesco Paolo Lovergine, Robert Luberda
and Stefano Zacchiroli.  Those maintainers have actually
put quite a bit of work into the package (thanks), so it's
in pretty good shape, only it badly wants a data update
from upstream.  It may want a few other things, too.

On Thu, Oct 27, 2016 at 09:00:57AM +0800, Paul Wise wrote:
> I think you mean 200 MiB?

That's right.  Thanks.
 
> I'd suggest a package 'salvage', add yourself to
> the Uploaders. If the maintainer never surfaces, you can
> then remove them from Maintainer.

Okay.  If the present NMU works out all right and the
current maintainer does not resurface, then I'll consider it.
This and your other advice sound like good ideas.



signature.asc
Description: Digital signature

Bug#842252: ITP: elpa-eshell-up -- quickly go to a specific parent directory in eshell

[Lev Lamberov]

Package: wnpp
Severity: wishlist
Owner: Lev Lamberov 

* Package name: elpa-eshell-up
  Version : 0.0.3
  Upstream Author : Peter W. V. Tran-Jørgensen 
* URL : https://github.com/peterwvj/eshell-up
* License : GPL-3+
  Programming Lang: Emacs Lisp
  Description : quickly go to a specific parent directory in eshell

Package for quickly navigating to a specific parent directory in eshell
without having to repeatedly typing 'cd ..'.  This is achieved using the
`eshell-up' function, which can be bound to an eshell alias such as `up'.

Bug#842255: ITP: node-set-value -- Create nested values and any intermediaries using dot notation (`'a.b.c'`) paths

[Pirate Praveen]

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

* Package name: node-set-value
  Version : 0.4.0
  Upstream Author : Jon Schlinkert (https://github.com/jonschlinkert)
* URL : https://github.com/jonschlinkert/set-value
* License : Expat
  Programming Lang: JavaScript
  Description : Create nested values and any intermediaries using
dot notation (`'a.b.c'`) paths.



signature.asc
Description: OpenPGP digital signature

Re: Planned NMU of w3-recs would use much archive disk space

[Thaddeus H. Black]

On Thu, Oct 27, 2016 at 08:41:12AM -0200, Henrique de Moraes Holschuh wrote:
> so I'd say go ahead even if it is 200GiB.

That would be pretty amazing.  It's 200MiB, of course, as
you and Paul note.

> That said, Thaddeus, if you do go ahead with the upload please check if
> you can minimize that size somehow, even just a 10% drop in size would
> already be worth the work it took for something big like this.

Yes, this is a good point.  Part of the problem, however -- if
it is indeed a problem -- regards an apparently complicated
situation upstream.  Upstream of w3-recs is currently less
orderly than upstream of doc-rfc (this is not a criticism of
upstream; there are reasons for the comparative disorder; FLOSS
developers are probably not responsible).  Without inserting
the Debian Project in any way into internal upstream processes,
I believe that I have unraveled the upstream knot sufficiently
to update our package w3-recs in a more or less sensible way.

In light of the situation upstream, five years ago, the
maintainer of our w3-recs package made the probably correct
decision to include in the package not only documents upstream
had blessed as REC (recommendation), but also documents in the
upstream statuses of PR (proposed recommendation)
and CR (candidate recommendation).  For better or for worse,
the HTML 5.1 specification (PR) normatively references several
mere working drafts (WD).  Most of the referenced working
drafts are actually in pretty good shape; but, at any rate, you
don't have a clear line any more between actual standards and
mere drafts.

Most likely, when the torrid pace of development of the
relevant standards slows down again, upstream will eventually
restore better order; but, until then, this is what we've got.

So, I'd have to do some curation, rejecting some documents and
accepting others.  The result would be imperfect but
nevertheless quite useful, and would be much better than the
obsolete w3-recs we have now.

> For example, suppose it ships the recommendations in several rendered
> formats (PDF, PS, HTML/XHTML) and master hypertext (XML DOCBOOK,
> whatever).  It would be quite acceptable to drop everything but the
> xhtml/html+css+images versions from the binary packages: people won't
> install these to print, they will install them to read while working on
> something (code, documents, etc) or researching, and browser-friendly
> hypertext is MUCH better for search, cut-and-paste, reading, and
> alternative renderings (voiced, etc) than PDF/PS/etc.

This is a good idea.  I'll do it.

I am aware of one redistributable document only available as
a PDF (remember that w3-recs is non-free); but your advice
works for all the others as far as I know.



signature.asc
Description: Digital signature

Re: openssl transition

[Dimitri John Ledkov]

Hello,

On 27 October 2016 at 11:40, Jörg Frings-Fürst
 wrote:
> Hello,
>
> I have read the discussion about the openssl transition here again.
>
> One of the last notes was to be used openssl 1.0 and 1.1 in parallel
> because of the non-trivial changes.
>
> So I have some questions:
>
> - The parallel use of release 1.0 and 1.1 will not be pursued?
>
> - Why is the transition started with 0 (zero) good packages (from 552)?
>

I do not see that a transition has started.

There are bug reports tagged for the transition:
https://udd.debian.org/cgi-bin/bts-usertags.cgi?tag=openssl-1.1-trans&user=pkg-openssl-devel-request%40lists.alioth.debian.org
https://udd.debian.org/cgi-bin/bts-usertags.cgi?tag=openssl-1.1-trans-keypkg&user=pkg-openssl-devel-request%40lists.alioth.debian.org

There is 1.1 openssl in experimental:
https://tracker.debian.org/pkg/openssl

This did trigger an automated transition tracker to be created:
https://release.debian.org/transitions/html/auto-openssl.html

But do note that "This tracker was setup by a very simple automated
tool. The tool may not be very smart..."

However no transition has started. Transitions only start once the new
ABI is uploaded into unstable, which has not happened.

> - Should it be safer to switch to a new API at short notice and
> under  pressure?
>
>
> CU
> Jörg
> --
> New:
> GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
> GPG key (long) : 09F89F3C8CA1D25D
> GPG Key: 8CA1D25D
> CAcert Key S/N : 0E:D4:56
>
> Old pgp Key: BE581B6E (revoked since 2014-12-31).
>
> Jörg Frings-Fürst
> D-54470 Lieser
>
> Threema: SYR8SJXB
>
> IRC: j_...@freenode.net
>  j_...@oftc.net
>
> My wish list:
>  - Please send me a picture from the nature at your home.



-- 
Regards,

Dimitri.

Re: "PIE by default" transition is underway -- wiki needs updating

[Bálint Réczey]

Hi,

2016-10-27 4:03 GMT+02:00 Steve M. Robbins :
> On Wed, Oct 26, 2016 at 05:26:24AM +0200, Guillem Jover wrote:
>
>> My point was that, yes we have changed to generating relocatable code
>> but that is still targetted for executables only, which preserves the
>> current behavior, [...]
>
> But something must have changed with how a static lib is now compiled,
> because (a) I see bug reports saying "foo broke because static libbar
> is not -fPIC" and (b) the recommended fix is to rebuild libbar with
> the new toolchain -- with no source changes.
>
> So what's going on with static libs?

As a preparation for the transition I suggested using PIC for static
libraries for some packages and also suggested changing the Policy
to be more liberal about that.  (#837478)
I followed the current Policy and opened discussion on debian-devel
before enabling PIC in the affected packages:
https://lists.debian.org/debian-devel/2016/09/msg00277.html

I have updated some of the affected packages according the current
Policy.

A few weeks later Adrian shared his concerns with this approach
and preferred simple binNMU-s for affected static librarie because
it also fixes the build issues. The reasoning can be read in the same
bug.

Some binNMU-s already took place.
Adrian also filed bugs for reverting the changes enabling PIC for
static libraries.

This is where we are now. I guess the rest of the binNMUs will take
place soonish. The Policy may or may not be changed depending on
new inputs in #837478.

Cheers,
Balint

Re: openssl transition

[Antti Järvinen]

Jörg Frings-Fürst writes:

 > I have read the discussion about the openssl transition here again.

Possibly referring to 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=827061 ??

 > - The parallel use of release 1.0 and 1.1 will not be pursued?

Might be highly problematic, having purposefully 2 different versions
of the same library in same process isn't the brightest idea. Real 
world example is any application that links openssl and qt library. 
Should you link different openssl version than the one used by qt 
will ..produce interesting results :)

LibreOffice comes to my mind next, it pulls openssl via number of
different libraries like database drivers. 

While patching -DOPENSSL_API_COMPAT=0x1010L will help a lot but
code changes are still required in addition to this flag, many
applications allocate OpenSSL data-structures in stack and this is not
supported any more, regardless of -DOPENSSL_API_COMPAT.

--
Antti

Bug#842263: ITP: pd-punish -- a collection of hacks for the Pd User Interface

[IOhannes m zmoelnig]

Package: wnpp
Severity: wishlist
Owner: IOhannes m zmoelnig 

* Package name: pd-punish
  Version : 0.0
  Upstream Author : IOhannes m zmölnig 
* URL : https://git.iem.at/pd-gui/punish/
* License : GPL
  Programming Lang: C, Tcl/Tk
  Description : a collection of hacks for the Pd User Interface

 punish is IEM's collection of Pure Data User Interface Hacks.
 It contains the following dearly needed plugins for the Pd-GUI:
 - triggerize: fix the dreaded fan-out by inserting [trigger]s where needed.
 - patcherize: refactor your code into modules (abstractions, sub-patches).

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

Bug#842265: ITP: node-unset-value -- Delete nested properties from an object using dot notation

[Sruthi Chandran]

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

* Package name: node-unset-value
  Version : 0.1.1
  Upstream Author : Jon Schlinkert (https://github.com/jonschlinkert)
* URL : https://github.com/jonschlinkert/unset-value
* License : Expat
  Programming Lang: JavaScript
  Description : Delete nested properties from an object using dot
notation

Bug#842274: ITP: node-static-extend -- Adds a static `extend` method to a class, to simplify inheritance

[Sruthi Chandran]

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

* Package name: node-static-extend
  Version : 0.1.2
  Upstream Author : Jon Schlinkert (https://github.com/jonschlinkert)
* URL : https://github.com/jonschlinkert/static-extend
* License : Expat
  Programming Lang: JavaScript
  Description : Adds a static `extend` method to a class, to
simplify inheritance. Extends the static properties, prototype
properties, and descriptors from a `Parent` constructor onto `Child`
constructors.

Bug#842275: ITP: libstatistics-welford-perl -- Standard statistics using Welford's algorithm

[Axel Beckert]

Package: wnpp
Owner: Axel Beckert 
Severity: wishlist

* Package name: libstatistics-welford-perl
  Version : 0.02
  Upstream Author : Kaare Rasmussen 
* URL : https://metacpan.org/release/Statistics-Welford
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Standard statistics using Welford's algorithm

Statistics::Welford provides standard statistics (mean value,
variance, standard deviation, minimum and maximum value as well as
the number of elements) using Welford's algorithm.

Welford's algorithm is much more efficient compared to the naïve
algorithm implemented in e.g. Statistics::Basic::StdDev. It especially
does not need to load all values into RAM at the same time.

The package will be maintained under the umbrella of the Debian Perl
Group.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Re: Keysafe dynamic UID

[Anthony DeRobertis]

On Sun, Oct 23, 2016 at 04:59:20PM +0200, Guillem Jover wrote:
> 
> Also renaming a user is actually trivial:
> 
>   usermod -l _something Debian-something
> 

Unfortunately those names also get into various cron tabs, config files,
etc. Doing that with, e.g., Debian-exim would immediately break my mail
server, for example.

I wonder if just adding a second user with the same uid would be safer
(so then the packaged scripts can use the new name), and documenting
that the old one will be removed for the next release?

(Also, I haven't tested: does that properly handle group memberships?)

Re: openssl transition

[Russ Allbery]

Dimitri John Ledkov  writes:

> However no transition has started. Transitions only start once the new
> ABI is uploaded into unstable, which has not happened.

The release team asked for all the OpenSSL bugs to be upgraded to RC,
which is probably what triggered this discussion.  (I was a bit surprised
too; that's quite a lot of packages to yank from testing by the middle of
next month for problems that will often require upstream fixes.  But hey,
it does get people motivated, and it's certainly increased my motivation
to work out a fix for a quasi-orphaned package I still maintain, sort of.)

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

Bug#842297: ITP: mapbox-vector-tile -- Mapbox Vector Tile library for Python

[Bas Couwenberg]

Package: wnpp
Severity: wishlist
Owner: Bas Couwenberg 

* Package name: mapbox-vector-tile
  Version : 0.5.0+ds
  Upstream Author : Harish Krishna 
* URL : https://github.com/tilezen/mapbox-vector-tile
* License : Expat
  Programming Lang: Python
  Description : Mapbox Vector Tile library for Python

mapbox-vector-tile provides encoding & decoding support for data
conforming to the Mapbox Vector Tile specification in Python.


mapbox-vector-tile is required for the new TileStache upstream releases,
and the package will be maintained alongside TileStache in the Debian
GIS team.

Bug#842298: ITP: california -- calendar application for GNOME 3

[Sebastian Reichel]

Package: wnpp
Severity: wishlist
Owner: Sebastian Reichel 

* Package name: california
  Version : 0.4.0
  Upstream Author : Jim Campbell 
* URL : https://wiki.gnome.org/Apps/California
* License : LGPL-2.1
  Programming Lang: Vala
  Description : calendar application for GNOME 3

California is a calendar built for GNOME 3. It allows you to
view and manage your online calendars with a simple and modern
interface. It uses EDS (Evolution Data Server) as the back-end
for managing your calendars. If you've already added calendars
to EDS via another application (such as Evolution), you should
be able to see those calendars in California as well.

I have packaging ready at [0] and intend to upload it, if it
turns out to be useful on small screens as found in smartphones.

[0] https://anonscm.debian.org/cgit/pkg-gnome/california.git

-- Sebastian

Re: When should we https our mirrors?

[Tollef Fog Heen]

]] David Kalnischkies 

> I would kinda like to avoid encoding the entire answer and sending that
> in for display because it would be a lot of noise (and bugreporters will
> truncate it if it is too long trying to be helpful), so if people who
> actually know what they would need to deal with issues (I don't) would
> decide upon a set and report a bug against apt to implement it, we will
> see what we can do.

It would be great if we could have all of it (dropped in a log file
would probably be ok, we can then ask for it from the user).

> P.S.: Fastlys Via response header seems to be important, given that it
> is sent twice, but apart from that…

Not really, it's just that it passes through multiple caches on the way.

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

Bug#842306: ITP: falco -- Sysdig Falco is a behavioral activity monitor designed to detect anomalous activity in your applications

[Julien Rabier]

Package: wnpp
Severity: wishlist
Owner: Julien Rabier 

* Package name: falco
  Version : 0.4.0
  Upstream Author : Sysdig 
* URL : http://www.sysdig.org/falco/
* License : GPLv2
  Programming Lang: C++, C
  Description : Sysdig Falco is a behavioral activity monitor designed to
detect anomalous activity in your applications.

Powered by sysdig’s system call capture infrastructure, falco lets you
continuously monitor and detect container, application, host, and network
activity... all in one place, from one source of data, with one set of rules.

I use Sysdig and Falco professionnally and would like to package and maintain
Falco in Debian.

Re: When should we https our mirrors?

[Philipp Kern]

On 10/27/2016 12:40 PM, Russell Stuart wrote:
> It's *far* better than httpredir.  But given adding httpredir as a
> backup has become a net negative for me, that's not saying much. 
> deb.debian.org so far has been net positive.

As a counter-point - in order to give credit where it's due - I had
little problems with httpredir in Germany and it almost always maxes out
my 100 Mbit/s connection by fetching from three well connected mirrors
at the same time.

But I figure that this might be unique to my first-world networking
situation and the fact that mirrors close to me are likely up-to-date
and maintained.

I know other distributions do things like letting the user netselect for
the closest mirror (which really doesn't mean much). But now with
deb.debian.org we also end up with two different CDNs with vastly
different characteristics. I'll note that it also only tells you how to
pin one of the two CDNs on its homepage. Maybe we could fix that and
then let users pick one rather than letting everyone round-robin between
them... (Something in me wants to tongue-in-cheek suggest to couple
httpredir and deb.debian.org to pick the sanest CDN for the user.)

Kind regards
Philipp Kern



signature.asc
Description: OpenPGP digital signature

Re: Keysafe dynamic UID

[Ian Jackson]

Anthony DeRobertis writes ("Re: Keysafe dynamic UID"):
> I wonder if just adding a second user with the same uid would be safer
> (so then the packaged scripts can use the new name), and documenting
> that the old one will be removed for the next release?

This is an idea worth pursuing.

> (Also, I haven't tested: does that properly handle group memberships?)

I'm not sure.  Testing would be needed.

Other questions: what happens if attempts are made to lock the
account, or whatever.  (I suspect it's only one of the names that's
disabled.)

Also, in each case we'd have to check whether the software would be
likely to go wrong due to unexpected results from uid->name mapping.
(IME one gets the first matching entry found in /etc/passwd).

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: openssl transition

[Ian Jackson]

Russ Allbery writes ("Re: openssl transition"):
> The release team asked for all the OpenSSL bugs to be upgraded to RC,
> which is probably what triggered this discussion.  (I was a bit surprised
> too; that's quite a lot of packages to yank from testing by the middle of
> next month for problems that will often require upstream fixes.  But hey,
> it does get people motivated, and it's certainly increased my motivation
> to work out a fix for a quasi-orphaned package I still maintain, sort of.)

I got a copy of the mail fom the BTS about this but I still haven't
figured out which package it relates to :-/.  I worry that I have
subscribed to a package in an incomplete way (ddpo only or maybe bts
only) and it's going to be removed and I will notice too late...

I keep meaning to try to find a way to figure out what package(s) it
might be, that isn't eyeballing the list.

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: When should we https our mirrors?

[Adam Borowski]

On Thu, Oct 27, 2016 at 08:35:18AM +0200, Vincent Bernat wrote:
>  ❦ 17 octobre 2016 20:49 +0200, Vincent Bernat  :
> >> TL;DR: Would we now recommend deb.d.o over httpredir.d.o for production
> >> use e.g. in base images (including for Jessie)?
> 
> When I said that, I was using cdn-fastly-v6.deb.debian.org (to also
> force use of IPv6 which is still in beta at fastly). I have now tried
> deb.debian.org and in a few days, I got numerous hash mismatchs that are
> solved only after a few apt-get update (while with Fastly, the
> occurrence of those are pretty rare and always solved with one apt-get
> update).
> 
> I seem to always get redirected to Cloudfront. Moreover, the download
> speed can be very slow, either from work or from home (100M fiber
> connection). Sometimes 100kbytes/s. That's a pain.
> 
> I am a bit worried for deb.debian.org to become a default as it doesn't
> work well for me. Am I alone to have such problems?

Me too, and I live in the middle of Europe, without such problems as a
SSL-blocking Golden Shield or abysmal international links.

Despite many fast mirrors nearby, deb.debian.org almost always connects me
to a server in the US (I got NL just once).  Tried from three ISPs.

So if this CDN has problems in France and Poland, I don't see it working
right in China, Iran or Cuba.


Meow!
-- 
A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol, 1kg
raspberries, 0.4kg sugar; put into a big jar for 1 month.  Filter out and
throw away the fruits (can dump them into a cake, etc), let the drink age
at least 3-6 months.

Re: openssl transition

[Jonas Smedegaard]

Quoting Ian Jackson (2016-10-28 01:00:25)
> Russ Allbery writes ("Re: openssl transition"):
> > The release team asked for all the OpenSSL bugs to be upgraded to 
> > RC, which is probably what triggered this discussion.  (I was a bit 
> > surprised too; that's quite a lot of packages to yank from testing 
> > by the middle of next month for problems that will often require 
> > upstream fixes.  But hey, it does get people motivated, and it's 
> > certainly increased my motivation to work out a fix for a 
> > quasi-orphaned package I still maintain, sort of.)
> 
> I got a copy of the mail fom the BTS about this but I still haven't 
> figured out which package it relates to :-/.  I worry that I have 
> subscribed to a package in an incomplete way (ddpo only or maybe bts 
> only) and it's going to be removed and I will notice too late...
> 
> I keep meaning to try to find a way to figure out what package(s) it 
> might be, that isn't eyeballing the list.

Try check the email headers - in my experience often there is am 
X-somethind line added hinting about the specific package.


 - 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

Work-needing packages report for Oct 28, 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: 974 (new: 13)
Total number of packages offered up for adoption: 154 (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:

   aspell-uz (#841695), orphaned 5 days ago
 Description: The Uzbek dictionary for GNU Aspell
 Installations reported by Popcon: 18
 Bug Report URL: http://bugs.debian.org/841695

   ibus-tegaki (#841823), orphaned 4 days ago
 Description: tegaki engine for IBus
 Installations reported by Popcon: 34
 Bug Report URL: http://bugs.debian.org/841823

   mpg123-el (#841815), orphaned 4 days ago
 Description: front-end to mpg321/ogg321 media players for Emacs
 Installations reported by Popcon: 52
 Bug Report URL: http://bugs.debian.org/841815

   pinyin-database (#841817), orphaned 4 days ago
 Description: PinYin database used by ibus-pinyin
 Installations reported by Popcon: 90
 Bug Report URL: http://bugs.debian.org/841817

   qterm (#841821), orphaned 4 days ago
 Description: BBS client for X Window System written in Qt
 Installations reported by Popcon: 34
 Bug Report URL: http://bugs.debian.org/841821

   tegaki-pygtk (#841810), orphaned 4 days ago
 Description: GTK+ widget Python model for Tegaki
 Reverse Depends: ibus-tegaki tegaki-recognize tegaki-train
 Installations reported by Popcon: 76
 Bug Report URL: http://bugs.debian.org/841810

   tegaki-python (#841814), orphaned 4 days ago
 Description: core Python module of Tegaki
 Reverse Depends: python-tegaki-gtk python-tegakitools tegaki-train
 Installations reported by Popcon: 76
 Bug Report URL: http://bugs.debian.org/841814

   tegaki-recognize (#841816), orphaned 4 days ago
 Description: handwriting recognition application
 Installations reported by Popcon: 39
 Bug Report URL: http://bugs.debian.org/841816

   tegaki-tools (#841811), orphaned 4 days ago
 Description: command-line tools for Tegaki
 Installations reported by Popcon: 15
 Bug Report URL: http://bugs.debian.org/841811

   tegaki-train (#841813), orphaned 4 days ago
 Description: train tegaki with your own handwriting
 Installations reported by Popcon: 17
 Bug Report URL: http://bugs.debian.org/841813

   tegaki-zinnia-japanese (#841819), orphaned 4 days ago
 Description: Japanese handwriting model for Zinnia
 Reverse Depends: fcitx-mozc ibus-mozc mozc-utils-gui
 Installations reported by Popcon: 620
 Bug Report URL: http://bugs.debian.org/841819

   tegaki-zinnia-simplified-chinese (#841818), orphaned 4 days ago
 Description: Simplified Chinese handwriting model for Zinnia
 Installations reported by Popcon: 26
 Bug Report URL: http://bugs.debian.org/841818

   uzbek-wordlist (#841696), orphaned 5 days ago
 Description: The Uzbek dictionary for Hunspell
 Reverse Depends: parl-desktop-world
 Installations reported by Popcon: 25
 Bug Report URL: http://bugs.debian.org/841696

961 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 154 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 4384 days ago
 Description: Enable powersaving mode for Athlon/Duron processors
 Installations reported by Popcon: 21
 Bug Report URL: http://bugs.debian.org/278442

   awstats (#755797), requested 827 days ago
 Description: powerful and featureful web server log analyzer
 Installations reported by Popcon: 4096
 Bug Report URL: http://bugs.debian.org/755797

   balsa (#642906), requested 1859 days ago
 Description: An e-mail client for GNOME
 Reverse Depends: balsa-dbg
 Installations reported by Popcon: 676
 Bug Report URL: http://bugs.debian.org/642906

   cardstories (#624100), requested 2012 days ago
 Description: Find out a card using a sentence made up by another
   player
 Installations reported by Popcon: 7
 Bug Report URL: http://bugs.debian.org/624100

   courier (#823807), requested 171 days ago
 Description: Courier mail server
 Reverse Depends: courier-faxmail courier-filter-perl courier-imap
   courier-imap-ssl courier-ldap courier-mlm courier-mta
   courier-mta-ssl courier-pcp courier-pop (7 more omitted)
 Installations reported by Popcon: 2

Re: When should we https our mirrors?

[Guillem Jover]

Hi!

On Mon, 2016-10-24 at 11:51:00 -0400, Paul Tagliamonte wrote:
> On Mon, Oct 24, 2016 at 04:00:39PM +0100, Ian Jackson wrote:
> > It is also evident that there are some challenges for deploying TLS on
> > a mirror network and/or CDN.  I don't think anyone is suggesting
> > tearing down our existing mirror network.
> 
> https://deb.debian.org/ is now set up (thanks, folks!), so my attention
> is now shifted away from the push to https all the things (not everyone
> will, so I just want a stable well-used domain that could be a sensable
> default, and let those who don't want to move forward stay in the past)
> and on to considering the apt https transport and thoughts on how this
> could become part of the base install.

Ah nice, and since few days it seems this also carries the debian-debug
archives! Awesome, thanks.

Thanks,
Guillem

Heads-up: Switching internal dpkg arch representation to quadruplets

[Guillem Jover]

Hi!

Currently dpkg represents architectures internally as Debian triplets,
which have the inverse order as GNU triplets. One problem is that the
first element of the triplet encodes the ABI and the libc used, so we
have no way to wildcard one or the other, and this is becoming more
relevant with new arches targetting different libcs or same non-base
ABIs. This is one of the problems I'm tracking as part of the time-travel
fixes . :)

I never made the full triplets a "public interface" because I was worried
that exactly this could happen, and that's why this is hinted at in the
policy manual, but not explicitly documented.

This affects mostly triplet wildcards concerning the following ABIs:

  eabi eabihf abin32 abi64 spe x32

So, where we could previously have the wildcard “uclibc-linux-any”,
it would not match “uclibc-linux-armel” because that is represented
internally as “uclibceabi-linux-arm”; or “gnu-any-any” would not match
none of “kfreebsd-armhf”, “mipsn32r6el”, nor “x32” for example.

This change fixes this so that we can match on each proper element of
the tuple by making it a quadruplet, and by making that a public
interface. So now we'll be able to match on any ARM EABI HF arch with
“eabihf-any-any-arm” or any glibc based arch “any-gnu-any-any” or with
its shorter form “gnu-any-any” and similar other combinations. In
particular this means that the semantics have changed and backwards
compatibility is somewhat "broken" if such undocumented wildcard triplets
were used; which they will match on more things (for example the above
mentioned “gnu-any-any”).

The current working branch for this can be found at:

  


which I'm planning to merge for dpkg 1.18.11, in principle targetted for
release this week. But if people see some serious problem with the plan,
I'm fine delaying it another release while any missing details are
hammered down?

This changes private module functions, and makes dpkg-architecture
additionally expose DEB_*_ARCH_ABI and DEB_*_ARCH_LIBC, which could
be stuff like eabi/eabihf/n32/spe/etc and gnu/musl/uclibc/etc
respectively. It also first versions the arch tables so that future
changes can be handled more gracefully, and second changes the internal
representation, which will affect some projects; the ones I'm aware of
are at least rebootstrap, botch, dose3 and dak (all maintainers BCCed).

I've not checked the archive this time around, I think we did so some
time ago, but I doubt we are using triplet wildcards there? Which would
be another possible cause of breakage.

Thanks,
Guillem

Re: When should we https our mirrors?

[Tollef Fog Heen]

]] Adam Borowski 

> Despite many fast mirrors nearby, deb.debian.org almost always connects me
> to a server in the US (I got NL just once).  Tried from three ISPs.

Is this on IPv6 or legacy IP?  The former is known to be less-than-ideal
routing-wise in a bunch of cases and I'll talk to Fastly to see if we
can get a process to get this improved, but this should be rare(r) for
legacy IP.

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

Re: Bug#842306: ITP: falco -- Sysdig Falco is a behavioral activity monitor designed to detect anomalous activity in your applications

[Tollef Fog Heen]

]] Julien Rabier 

> Powered by sysdig’s system call capture infrastructure, falco lets you
> continuously monitor and detect container, application, host, and network
> activity... all in one place, from one source of data, with one set of rules.
> 
> I use Sysdig and Falco professionnally and would like to package and maintain
> Falco in Debian.

Yay, great to see this packaged!  I've wanted to poke at it for a while,
but ENOTIME so far.

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

Bug#842321: ITP: node-indent-string -- Indent each line in a string

[Sarath M S]

Package: wnpp
Severity: wishlist
Owner: Sarath M S 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: node-indent-string
  Version : 3.0.0
  Upstream Author : Sindre Sorhus 
(sindresorhus.com)
* URL : https://github.com/sindresorhus/indent-string#readme
* License : Expat
  Programming Lang: JavaScript
  Description : Indent each line in a string

 A node.js module that provides API for to indent lines in a string. 
 .
 Node.js is an event-based server-side JavaScript engine.




signature.asc
Description: OpenPGP digital signature

Bug#842322: ITP: node-load-json-file -- Read and parse a JSON file

[Pirate Praveen]

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

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



signature.asc
Description: OpenPGP digital signature

Bug#842323: ITP: node-validate-npm-package-license -- Tells if a string is a valid npm package license string

[Sruthi Chandran]

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

* Package name: node-validate-npm-package-license
  Version : 3.0.1
  Upstream Author : Kyle E. Mitchell 
(https://kemitchell.com)
* URL :
https://github.com/kemitchell/validate-npm-package-license.js#readme
* License : Apache-2.0
  Programming Lang: JavaScript
  Description : Tells if a string is a valid npm package license string

Bug#842325: ITP: node-arr-diff -- Returns an array with only the unique values from the first array

[Sruthi Chandran]

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

* Package name: node-arr-diff
  Version : 3.0.0
  Upstream Author : Jon Schlinkert (https://github.com/jonschlinkert)
* URL : https://github.com/jonschlinkert/arr-diff
* License : Expat
  Programming Lang: JavaScript
  Description : Returns an array with only the unique values from
the first array, by excluding all values from additional arrays using
strict equality for comparisons.