Bug#841158: ITP: node-is-arrayish -- Determines if an object can be used as an array

[Shanavas M]

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

* Package name   : node-is-arrayish
  Version  : 0.3.0
  Upstream Author: Qix (http://github.com/qix-)
* URL  : https://github.com/qix-/node-is-arrayish#readme
* License : Expat
  Programming Lang : JavaScript
  Description: Determines if an object can be used as an array

 A Nodejs module to determine if an object can be used as an array
 .
 Node.js is an event-based server-side JavaScript engine.

Bug#841159: ITP: node-filename-regex -- Regular expression for matching file names, with or without extension

[Sruthi Chandran]

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

* Package name: node-filename-regex
  Version : 2.0.0
  Upstream Author : Jon Schlinkert (https://github.com/jonschlinkert)
* URL : https://github.com/regexps/filename-regex
* License : Expat
  Programming Lang: JavaScript
  Description : Regular expression for matching file names, with or
without extension

Re: When should we https our mirrors?

[Philipp Kern]

On 10/17/2016 08:48 PM, Cyril Brulebois wrote:
> Philipp Kern  (2016-10-17):
>> On 10/17/2016 05:39 PM, Cyril Brulebois wrote:
>>> AFAICT from a recent https deployment, apt will perform a TLS handshake
>>> for each and every file it downloads from the mirror; including indices,
>>> translations, pdiffs, and finally debian packages.
>> Last I checked it pipelined within a single TLS connection (well, one
>> per host). A casual Wireshark seems to confirm that.
> Ah. What I saw might have been due to client cert auth then? I guess I
> should revisit this setup when I find more time. There's also Pipeline-
> Depth option's being advertised as not supported for https, too.

We use it with a TPM-backed client certificate, so redoing the handshake
all the time would be quite slow. cURL keeps open connections around in
its handle as created by curl_easy_init().

Kind regards
Philipp Kern



signature.asc
Description: OpenPGP digital signature

Re: Package name conflict question

[林上智]

Hi Adam,

Thanks for your reply.

Although these packages are not API-compatible, they are using the
same installation path and file name; therefore, I think "Conflict:"
section is needed.


--
Sun-Ze Lin  (林上智)


2016-10-17 2:27 GMT+08:00 Adam Borowski :

> On Sun, Oct 16, 2016 at 10:36:31AM +0200, Christian Seiler wrote:
> > On 10/16/2016 10:07 AM, Alec Leamas wrote:
> > > On 16/10/16 09:35, SZ Lin (林上智) wrote:
> > >> I want to package python library - *uritemplate* [1]; however, I found
> > >> that  there is a same name package with similar function in Debian
> > >> archive [3].
> >
> > You'd still need to add Conflicts: python-uritemplate to the package,
> > (because of the same Python package name) but that would make the new
> > package not coinstallable with the following rdepends:
> >
> > apt-cache rdepends python-uritemplate
> > python-uritemplate
> > Reverse Depends:
> >   python-googleapi
> >   slapos-client
> >   python-oauth2client
>
> If these packages are not API-compatible at least for their usual usage,
> Conflicts: is the wrong thing to do.  Please rename the new library
> instead.
>
> --
> 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.
>
>

kurze downtime der jenkins server um 12:00

[Harald Dunkel]

Hi folks,

zur RAM Erweiterung gibt es heute um 12:00 eine kurze Downtime
der Jenkins Server

invde8i001
mbrjenkins01
nvode7i001
semde7i001
sprjenkins01

Regards
Harri

Re: Package name conflict question

[Lars Wirzenius]

On Tue, Oct 18, 2016 at 03:36:56PM +0800, SZ Lin (林上智) wrote:
> Although these packages are not API-compatible, they are using the
> same installation path and file name; therefore, I think "Conflict:"
> section is needed.

The problem with this is that this prevents our users from having both
of them installed. These are Python libraries. Imagine a situation
where a user needs two applications and they depend on these two
libraries, one each? Having the libraries conflict with each other
means the user can't have both applications installed at the same
time. That would be unfortunate.

I don't have a solution for this. The ideal solution would be for one
or both upstream developers to rename their library. However, that's
only ideal in the long run, since it requires every program that uses
the libraries to be updated to use the new name.

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


signature.asc
Description: PGP signature

Re: Package name conflict question

[Ansgar Burchardt]

"SZ Lin (林上智)"  writes:
> Although these packages are not API-compatible, they are using the
> same installation path and file name; therefore, I think "Conflict:"
> section is needed.

Note that Policy explicitly forbids using "Conflicts" in this case, see
the first paragraph in [1].

  [1] 

Ansgar

Re: Bug#841099: ITP: node-has-values -- Returns true if any values exist, false if empty

[Vincent Bernat]

 ❦ 18 octobre 2016 09:08 +0800, Paul Wise  :

>> These are distinct packages, with distinct version numbers, and packages
>> will need to declare (potentially versioned) dependencies on them.
>
> Has anyone involved in the node ecosystem tried to talk the respective
> upstreams into creating a standard library that contains all these
> basic functions?

The community is quite proud of the number of packages they can maintain
and their minimalism. "Do one thing well". Here is my favorite example:

 https://github.com/sindresorhus/ama/issues/10#issuecomment-117766328

The author is one of the prominent personality of the JS community (and
author of a substantial portion of packages in npm).
-- 
Don't just echo the code with comments - make every comment count.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: Package name conflict question

[林上智]

Hi Ansgar,

Thanks for your reply.

I think this situation meets the condition.

The case of two programs having the same functionality but different
> implementations is handled via "alternatives" or the "Conflicts" mechanism.


These two programs having the same functionality - implementation of
RFC6570; but they aren't compatible with each other.

--
Sun-Ze Lin  (林上智)


2016-10-18 15:57 GMT+08:00 Ansgar Burchardt :

> "SZ Lin (林上智)"  writes:
> > Although these packages are not API-compatible, they are using the
> > same installation path and file name; therefore, I think "Conflict:"
> > section is needed.
>
> Note that Policy explicitly forbids using "Conflicts" in this case, see
> the first paragraph in [1].
>
>   [1] 
>
> Ansgar
>
>

Bug#841167: ITP: node-normalize-path -- Normalize file path slashes to be unix-like forward slashes

[Sruthi Chandran]

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

* Package name: node-normalize-path
  Version : 2.0.1
  Upstream Author : Jon Schlinkert (https://github.com/jonschlinkert)
* URL : https://github.com/jonschlinkert/normalize-path
* License : Expat
  Programming Lang: JavaScript
  Description : Normalize file path slashes to be unix-like forward
slashes. Also condenses repeat slashes to a single slash and removes and
trailing slashes.
Dependency for Grunt

Re: Debian and the node-js eco system

[W. Martin Borgert]

On 2016-10-17 21:25, Geert Stappers wrote:
> Thing I would like to see, is that all those "node js package" get
> their own component. ( 'main', 'contrib' and 'non-free' are components )

I personally dislike the Node.js nano-packaging approach, but
there is no fundamental reason why this dislike of ours should
prevent node packages from entering main.

The Node.js packages are free software and they are -
unfortunately - widely used by more and more projects, esp.
Grunt, a poor excuse for not using a Makefile.

IIRC, the new version of buildbot is partly written with
Node.js, Pump.io (the software running identi.ca) is written in
it, Grunt is needed by *many* packages to build nowadays.

This is not about packaging the complete Node.js eco system,
but packages, that are needed to package build tools such as
Grunt and applications we want to have in Debian.

Re: Package name conflict question

[Adam D. Barratt]

On 2016-10-18 9:52, SZ Lin wrote:

I think this situation meets the condition.


The case of two programs having the same functionality but different
implementations is handled via "alternatives" or the "Conflicts"
mechanism.


These two programs having the same functionality - implementation of
RFC6570; but they aren't compatible with each other.


"Same functionality" in this case implies the same interface, which you 
earlier indicated that the two Python modules don't have. That clause 
covers situations where package / implementation A can be swapped for 
package / implementation B without consumers needing to be aware of 
which is installed.


Regards,

Adam

Bug#841170: ITP: tendermint-go-logger -- Tendermint Go logging library

[Alessio Treglia]

Package: wnpp
Severity: wishlist
Owner: Alessio Treglia 

* Package name: tendermint-go-logger
  Version : Git snapshot
  Upstream Author : Tendermint project
* URL : http://www.tendermint.com/
* License : Apache-2.0
  Programming Lang: Golang
  Description : Tendermint Go logging library

This package provides logging utilities for Tendermint.
.
Tendermint is its own blockchain stack written from the
ground up and provides a Byzantine Fault Tolerant (BFT)
middleware that takes a state transition machine, written
in any programming language, and replicates it on many
machines.

Bug#841172: ITP: node-glob-parent -- Strips glob magic from a string to provide the parent path

[Sruthi Chandran]

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

* Package name: node-glob-parent
  Version : 3.0.0
  Upstream Author : Elan Shanker
* URL : https://github.com/es128/glob-parent
* License : ISC
  Programming Lang: JavaScript
  Description : Strips glob magic from a string to provide the
parent path
Dependency for Grunt

Bug#841175: ITP: python-dirq -- Python Directory Based Queue.

[Alvaro Lopez Garcia]

Package: wnpp
Severity: wishlist
Owner: Alvaro Lopez Garcia 

* Package name: python-dirq
  Version : 1.7.1
  Upstream Author : Konstantin Skaburskas 
* URL : https://github.com/cern-mig/python-dirq
* License : Apache2
  Programming Lang: Python
  Description : Python Directory Based Queue.
  
  The goal of this module is to offer a queue system using the
  underlying filesystem for storage, security and to prevent race
  conditions via atomic operations. It focuses on simplicity, robustness
  and scalability. This module allows multiple concurrent readers and
  writers to interact with the same queue.

Bug#841176: ITP: node-inflight -- Add callbacks to requests in flight to avoid async duplication

[Pirate Praveen]

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

* Package name: node-inflight
  Version : 1.0.6
  Upstream Author : Isaac Z. Schlueter  (http://blog.izs.me/)
* URL : https://github.com/isaacs/inflight
* License : ISC
  Programming Lang: JavaScript
  Description : Add callbacks to requests in flight to avoid async
duplication

For grunt.



signature.asc
Description: OpenPGP digital signature

Bug#841177: ITP: node-is-dotfile -- Return true if a file path is (or has) a dotfile

[Sruthi Chandran]

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

* Package name: node-is-dotfile
  Version : 1.0.2
  Upstream Author : Jon Schlinkert (https://github.com/jonschlinkert)
* URL : https://github.com/jonschlinkert/is-dotfile
* License : Expat
  Programming Lang: JavaScript
  Description : Return true if a file path is (or has) a dotfile.
Returns false if the path is a dot directory.
Dependency for Grunt

Bug#841178: ITP: nutsqlite -- dietary nutrition analysis software

[Iain R. Learmonth]

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

* Package name: nutsqlite
  Version : 1.9.9.2
  Upstream Author : Jim Jozwiak
* URL : http://nut.sourceforge.net/
* License : GPL-2
  Programming Lang: Tcl/Tk
  Description : Dietary nutrition analysis software

Features of NUT include:

 * The complete USDA database, your personal data, and the program code all 
stored in a portable SQLite database
 * Foods easy to find and add to daily meals
 * Configurable for 1-19 meals per day and any dietary plan--including 
ketogenic, low carb, zone, low fat
 * Comprehensive meal analysis for any number of consecutive meals
 * Presents both easy-to-read percentage summaries and in-depth nutrient 
analysis, including Omega-3 and Omega-6 essential fatty acids
 * Foods can be weighed in grams or ounces
 * Includes novel meal planning feature: you choose the food, NUT adjusts the 
quantities to your plan
 * Calorie Auto-Set feature uses linear regression on daily scale measurements 
of weight and body fat percentage to find optimal calorie level for improved 
body composition
 * Allows recording of recipes and customary meals for fast data entry
 * Sorts foods richest in each of the 150 nutrients
 * Reveals which foods contribute most to user's nutrition

--

This software will be packaged within the Debian Med team.

This software depends on the USDA food composition database which is in the
public domain.

  
https://www.ars.usda.gov/northeast-area/beltsville-md/beltsville-human-nutrition-research-center/nutrient-data-laboratory/docs/usda-national-nutrient-database-for-standard-reference/

This database will likely be packaged seperately, I need to check if other
packages already use this database in one way or another. It would also be cool
if compatible databases were available from other countries.

Debian Med is in CC, please follow up on this bug if you have opinions on the
packaging of the USDA food database.

Bug#820036: No bug mentioning a Debian KEK and booting use it.

[Ian Jackson]

Peter Dolding writes ("Bug#820036: No bug mentioning a Debian KEK and booting 
use it."):
> Yes it one thing to get shim signed by Microsoft.  Do remember
> Microsoft is free to push out updates to the  The Forbidden Signatures
> Database(dbx).
> 
> [etc.]

I'm afraid I can't make sense of this.  You have posted it to
debian-devel, but without any kind of sensible explanation of the
context.

Ian.

Re: [pkg-gnupg-maint] Bug#840669: Bug#840669: Beware of leftover gpg-agent processes

[Ian Jackson]

Daniel Kahn Gillmor writes ("Re: [pkg-gnupg-maint] Bug#840669: Bug#840669: 
Beware of leftover gpg-agent processes"):
> On Sat 2016-10-15 11:21:29 -0400, Ian Jackson wrote:
> > 1. gnupg1-compatible authorisation lifetime:
> 
> I believe this is a deliberate change in semantics from the upstream
> GnuPG project.  In particular, authorization for the use of secret key
> material is now the responsibility of the gpg-agent.  This is an overall
> win, because it means that no process ever gets access to the secret key
> in memory *except* for the gpg-agent.

I think these properties about key material handling are good, but
this is not the same question as the authorisation lifetime.  You are
conflating two separate things.

>  The gpg-agent is where these decisions are made.

Actually, though, it just acts as an oracle, so it does not make any
decisions.

> If you want an agent that never caches any passphrase (and therefore has
> a one-use-per-authorization), this is an easy thing to do by adjusting
> max-cache-ttl in gpg-agent.conf.  you can also set this dynamically with
> gpgconf (see the --runtime option in gpgconf(1)).

It sounds like this is very close to what I want for the authorisation
lifetime qeustion (provided that it isn't racy).  Why is this not the
default for command line users without a session-provided agent ?

> Thanks for your engagement on this issue, Ian.

Thank you for being so tolerant of me being argumentative !

Regards,
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: Package name conflict question

[Ian Jackson]

Lars Wirzenius writes ("Re: Package name conflict question"):
> I don't have a solution for this. The ideal solution would be for one
> or both upstream developers to rename their library. However, that's
> only ideal in the long run, since it requires every program that uses
> the libraries to be updated to use the new name.

This is less awful than it sounds because Python's `import' statement
can import module X but call it internally by the name Y.  So for most
callers, the required changes would be small and simple (if perhaps
numerous).  It might even be possible to do it mechanically.

Another approach would be to install the latecomer in a deviant path.
Then packaged applications which use the latecomer would modify
sys.path or PYTHONPATH somehow.  A compatibility module could be
provided which did this.

Ian.

-- 
Ian JacksonThese opinions are my own.

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

Re: Bug#820036: No bug mentioning a Debian KEK and booting use it.

[Paul Wise]

On Tue, Oct 18, 2016 at 7:36 PM, Ian Jackson wrote:

> I'm afraid I can't make sense of this.  You have posted it to
> debian-devel, but without any kind of sensible explanation of the
> context.

It was posted to bug #820036, which is tracking Debian support for
secure boot. Peter was advocating quite correctly that as well as
having our copy of shim (the first-stage bootloader on secure boot
systems) signed by Microsoft, we should also have a copy signed by a
Debian signing authority, so that users can theoretically choose to
distrust the Microsoft key. IIRC, unfortunately in practice that is
unlikely to be possible since various firmware blobs are only
Microsoft-signed.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: kurze downtime der jenkins server um 12:00

[Harald Dunkel]

Sorry for the noise, that was a bad To: address.

Regards
Harri

On 10/18/2016 09:14 AM, Harald Dunkel wrote:
> Hi folks,
> 
> zur RAM Erweiterung gibt es heute um 12:00 eine kurze Downtime
> der Jenkins Server
> 
>   invde8i001
>   mbrjenkins01
>   nvode7i001
>   semde7i001
>   sprjenkins01
> 
> Regards
> Harri
> 

Re: Is missing SysV-init support a bug?

[The Wanderer]

On 2016-10-17 at 17:53, Bart Schouten wrote:

> Nikolaus Rath schreef op 17-10-2016 18:26:
> 
>> On Oct 17 2016, Bart Schouten  wrote:
>> 
>>> (And I write SystemD with caps because that makes it easier to
>>> read, people invented capitals for a reason).
>> 
>> What would you think some people consistently spelled your name as
>> Bart SchouteN with the same justification?
> 
> I would consider that bigotry as SystemD is short pretty much for
> System Daemon.

While this is a reasonable point, it doesn't invalidate Nikolas' point:
that the people behind the systemd project A: do not consider it to be
spelled that way (and, yes, capitalization is part of correct spelling,
at least when it comes to names), B: are likely to perceive the refusal
to spell it in the way which they see as correct to be a sign of
hostility, and C: are likely to react accordingly to that perceived
hostility.

>> And if that set of people also happened to coincide exactly with
>> your most vocal critics?
>> 
>> How you write your emails is up to you, but you're not making it
>> likely for them to be well received.
> 
> Because I write the name of a project in the most reasonable
> capitalized form.

Without taking sides on the question at hand: do you, then, spell the
name of the distribution as DebIan?

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: dput: Call for testers: replacing ‘/usr/bin/gpg’ with GPGME

[Ben Finney]

Ben Finney  writes:

> I am preparing a new version of ‘dput’ that stops using ‘/usr/bin/gpg’,
> and instead uses the GPGME library for GnuPG operations.

> […]
> If your packaging workflow has unusual signing practices, or an unusual
> GnuPG configuration, your help will be especially valuable to test this
> change.

In particular I am seeking workflows and tests that:

* Use signatures from keys that are now expired, or from keys that your
  GnuPG doesn't trust, or from keys that your GnuPG doesn't know.

* Use signatures that are well-formed but fail to verify, or that are
  good but very old, or that are from the future.

* Use non-default hash algorithms, or non-default options that would
  otherwise affect the generated signature.

* Use GnuPG version 1 on a system with GnuPG 2, or vice versa.

* Use outdated versions of GPGME.

* etc.

I'm also hoping some people interested in back-porting ‘dput’ to older
Debian releases can help test these changes on those systems.

Please contact me at  to offer your packaging
system to test this new release.

-- 
 \“Good judgement comes from experience. Experience comes from |
  `\  bad judgement.” —Frederick P. Brooks |
_o__)  |
Ben Finney

Bug#841196: ITP: node-os-homedir -- Node.js 4 `os.homedir()` ponyfill

[Pirate Praveen]

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

* Package name: node-os-homedir
  Version : 1.0.2
  Upstream Author : Sindre Sorhus 
(sindresorhus.com)
* URL : https://github.com/sindresorhus/os-homedir#readme
* License : Expat
  Programming Lang: JavaScript
  Description : Node.js 4 `os.homedir()` ponyfill



signature.asc
Description: OpenPGP digital signature

Bug#841200: ITP: node-is-primitive -- Returns `true` if the value is a primitive

[Sruthi Chandran]

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

* Package name: node-is-primitive
  Version : 2.0.0
  Upstream Author : Jon Schlinkert (https://github.com/jonschlinkert)
* URL : https://github.com/jonschlinkert/is-primitive
* License : Expat
  Programming Lang: JavaScript
  Description : Returns `true` if the value is a primitive
Dependency for grunt

Bug#841202: ITP: node-pify -- Promisify a callback-style function

[Pirate Praveen]

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

* Package name: node-pify
  Version : 2.3.0
  Upstream Author : Sindre Sorhus 
(sindresorhus.com)
* URL : https://github.com/sindresorhus/pify
* License : Expat
  Programming Lang: JavaScript
  Description : Promisify a callback-style function



signature.asc
Description: OpenPGP digital signature

Bug#841206: ITP: node-fs.realpath -- Use node's fs.realpath

[Sruthi Chandran]

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

* Package name: node-fs.realpath
  Version : 1.0.0
  Upstream Author : Isaac Z. Schlueter  (http://blog.izs.me/)
* URL : https://github.com/isaacs/fs.realpath#readme
* License : ISC
  Programming Lang: JavaScript
  Description : Use node's fs.realpath, but fall back to the JS
implementation if the native one fails
   Dependency for Grunt

Re: Bug#841196: ITP: node-os-homedir -- Node.js 4 `os.homedir()` ponyfill

[Steve McIntyre]

Pirate Praveen wrote:
>-=-=-=-=-=-
>
>Package: wnpp
>Severity: wishlist
>Owner: Pirate Praveen 
>X-Debbugs-CC: debian-devel@lists.debian.org
>
>* Package name: node-os-homedir
>  Version : 1.0.2
>  Upstream Author : Sindre Sorhus 
>(sindresorhus.com)
>* URL : https://github.com/sindresorhus/os-homedir#readme
>* License : Expat
>  Programming Lang: JavaScript
>  Description : Node.js 4 `os.homedir()` ponyfill

/me args at YA tiny JS lump. It's tiny, and wrong. Probably. But it's
difficult to tell with such a small "Description". Please add some
useful text.

The code, well...

if (process.platform === 'linux') {
return home || (process.getuid() === 0 ? '/root' : (user ? 
'/home/' + user : null));
}

Things are more complicated than that. What exactly is this code meant
to be used for?

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
  Armed with "Valor": "Centurion" represents quality of Discipline,
  Honor, Integrity and Loyalty. Now you don't have to be a Caesar to
  concord the digital world while feeling safe and proud.

Bug#841212: ITP: node-signal-exit -- when you want to fire an event no matter how a process exits

[Sruthi Chandran]

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

* Package name: node-signal-exit
  Version : 3.0.1
  Upstream Author : Ben Coe 
* URL : https://github.com/tapjs/signal-exit
* License : ISC
  Programming Lang: JavaScript
  Description : when you want to fire an event no matter how a
process exits
  Dependency for Grunt

Re: Bug#841196: ITP: node-os-homedir -- Node.js 4 `os.homedir()` ponyfill

[Lars Wirzenius]

On Tue, Oct 18, 2016 at 03:27:46PM +0100, Steve McIntyre wrote:
> The code, well...
> 
>   if (process.platform === 'linux') {
>   return home || (process.getuid() === 0 ? '/root' : (user ? 
> '/home/' + user : null));
>   }
> 
> Things are more complicated than that. What exactly is this code meant
> to be used for?

This is so wrong, I would like to ask that this package not be allowed
into Debian until it's fixed.

A user's home directory in Unix is recorded in /etc/passwd, or in a
similar record accessed via a directory service of some kind. The
standard C library call for retrieving that information is getpwuid
(see manual page for details of usage). Note that reading /etc/passwd
directly is also not acceptable, you really do need to use the
standard interface (getpwuid) to get this right.

There is NO guarantee that root's home directory on a Unix system is
/root. /root might not even exist. Even if it exists, it might be
someone else's home directory. User foo's home directory might be
anywhere on the filesystem. It is true that on most Linux systems
/root is root's home directory, and /home/foo is foo's home directory,
but there are no guarantees whatsoever that this is actually true. If
you make this assumption, your code will break.

The FHS specifies /root as root's home directory, and /home where home
directories go, but the local sysadmin can override all of that. Also,
the local sysadmin can impose a hierarchy inside /home, and some do,
particularly on large sites.

Hardcoding assuptions like the code snippet above does is not just a
little buggy, it's a potential security problem. It is not infrequent
that a program needs to access files in a user's home directory, and
if it looks in the wrong place, that opens up an exploitable bug. If
you assume /root is root's home directory, and it's actually someone
else's directory, and you trust /root/.ssh/authorized_keys is root's
authorized ssh keys, you're going to have a bad time.

Trusting $HOME can be similarly dangerous for anything security
sensitive, but at least it is not quite as silly as hardcoding
assumptions in code.

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


signature.asc
Description: PGP signature

Re: Bug#841196: ITP: node-os-homedir -- Node.js 4 `os.homedir()` ponyfill

[Pirate Praveen]

On Tuesday 18 October 2016 07:57 PM, Steve McIntyre wrote:
> /me args at YA tiny JS lump. It's tiny, and wrong. Probably. But it's
> difficult to tell with such a small "Description". Please add some
> useful text.

This is packaged because its a dependency for grunt.

> The code, well...
> 
>   if (process.platform === 'linux') {
>   return home || (process.getuid() === 0 ? '/root' : (user ? 
> '/home/' + user : null));
>   }
> 
> Things are more complicated than that. What exactly is this code meant
> to be used for?
> 

It is a dependency for expand-tilde, which it turns comes in the
dependency chain for grunt.

All,

I don't particularly enjoy doing this either. Please direct your anger
at the nodejs developers. I'm doing this only because the packages I
care (diaspora and gitlab won't be accepted in main, unless I build
libjs-handlebars and libjs-fuzzaldrin-plus from its source).

This is Free Software, please send a pull request and convince upstream
developers whatever you wish.



signature.asc
Description: OpenPGP digital signature

Re: Bug#841196: ITP: node-os-homedir -- Node.js 4 `os.homedir()` ponyfill

[Steve McIntyre]

On Tue, Oct 18, 2016 at 08:40:49PM +0530, Pirate Praveen wrote:
>On Tuesday 18 October 2016 07:57 PM, Steve McIntyre wrote:
>> /me args at YA tiny JS lump. It's tiny, and wrong. Probably. But it's
>> difficult to tell with such a small "Description". Please add some
>> useful text.
>
>This is packaged because its a dependency for grunt.

That doesn't fix (or excuse) poor packaging, though.

>> The code, well...
>> 
>>  if (process.platform === 'linux') {
>>  return home || (process.getuid() === 0 ? '/root' : (user ? 
>> '/home/' + user : null));
>>  }
>> 
>> Things are more complicated than that. What exactly is this code meant
>> to be used for?
>
>It is a dependency for expand-tilde, which it turns comes in the
>dependency chain for grunt.
>
>All,
>
>I don't particularly enjoy doing this either. Please direct your anger
>at the nodejs developers. I'm doing this only because the packages I
>care (diaspora and gitlab won't be accepted in main, unless I build
>libjs-handlebars and libjs-fuzzaldrin-plus from its source).
>
>This is Free Software, please send a pull request and convince upstream
>developers whatever you wish.

Life's too short to go and fix all the crap in the world personally,
but we can keep certain minimum standards for what we as a group allow
into Debian. :-(

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Can't keep my eyes from the circling sky,
Tongue-tied & twisted, Just an earth-bound misfit, I...

Re: Bug#841196: ITP: node-os-homedir -- Node.js 4 `os.homedir()` ponyfill

[Pirate Praveen]

On Tuesday 18 October 2016 08:27 PM, Lars Wirzenius wrote:
> On Tue, Oct 18, 2016 at 03:27:46PM +0100, Steve McIntyre wrote:
>> The code, well...
>>
>>  if (process.platform === 'linux') {
>>  return home || (process.getuid() === 0 ? '/root' : (user ? 
>> '/home/' + user : null));
>>  }
>>
>> Things are more complicated than that. What exactly is this code meant
>> to be used for?
> 
> This is so wrong, I would like to ask that this package not be allowed
> into Debian until it's fixed.

This is already reported upstream
https://github.com/sindresorhus/os-homedir/issues/4



signature.asc
Description: OpenPGP digital signature

Re: Bug#841196: ITP: node-os-homedir -- Node.js 4 `os.homedir()` ponyfill

[Pirate Praveen]

On Tuesday 18 October 2016 08:45 PM, Steve McIntyre wrote:
> That doesn't fix (or excuse) poor packaging, though.

Are you saying this is RC? We have different level for bugs, this would
be wishlist. I don't mind someone writing a better description.

> Life's too short to go and fix all the crap in the world personally,
> but we can keep certain minimum standards for what we as a group allow
> into Debian. :-(
> 

But this is something we want in debian (grunt). I don't have to explain
Free Software model to you. If you find a bug, report it and if you can
send a patch, please do.

It seems there are so many people who focus on stopping other people...



signature.asc
Description: OpenPGP digital signature

Re: Bug#841196: ITP: node-os-homedir -- Node.js 4 `os.homedir()` ponyfill

[Pirate Praveen]

On Tuesday 18 October 2016 08:27 PM, Lars Wirzenius wrote:
> This is so wrong, I would like to ask that this package not be allowed
> into Debian until it's fixed.

I agree this could be marked RC and stopped from going to a stable
release. But do we stop accepting new packages in unstable because there
are serious bugs?




signature.asc
Description: OpenPGP digital signature

Re: Bug#841196: ITP: node-os-homedir -- Node.js 4 `os.homedir()` ponyfill

[Lars Wirzenius]

On Tue, Oct 18, 2016 at 08:49:27PM +0530, Pirate Praveen wrote:
> On Tuesday 18 October 2016 08:27 PM, Lars Wirzenius wrote:
> > This is so wrong, I would like to ask that this package not be allowed
> > into Debian until it's fixed.
> 
> This is already reported upstream
> https://github.com/sindresorhus/os-homedir/issues/4

Cool! I withdraw my objection once upstream fixes this bug.

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


signature.asc
Description: PGP signature

Re: Bug#841196: ITP: node-os-homedir -- Node.js 4 `os.homedir()` ponyfill

[Vincent Bernat]

 ❦ 18 octobre 2016 17:57 +0300, Lars Wirzenius  :

>> The code, well...
>> 
>>  if (process.platform === 'linux') {
>>  return home || (process.getuid() === 0 ? '/root' : (user ? 
>> '/home/' + user : null));
>>  }
>> 
>> Things are more complicated than that. What exactly is this code meant
>> to be used for?
>
> This is so wrong, I would like to ask that this package not be allowed
> into Debian until it's fixed.

This has already been reported:
 https://github.com/sindresorhus/os-homedir/issues/4

You can find other implementations that are also doing fishy stuff:
 https://github.com/wilmoore/node-homedir/blob/master/index.js

Author is usually hostile to get things right because it "works in 99%
of cases" (https://github.com/chalk/supports-color/pull/35).

At some point, the community will provide a decent standard lib instead
of the myriad of bad written modules. The leftpad issue helped a bit for
this. We have to bear with the low quality of those modules for now. If
we have to fix all the JS ecosystem ourselves, nothing will be done. And
we have seen in the past that is is pointless to alienate a community
(remember how violent the confrontation with the Ruby community was, 5
years ago).
-- 
Keep it right when you make it faster.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: Bug#841196: ITP: node-os-homedir -- Node.js 4 `os.homedir()` ponyfill

[Lars Wirzenius]

On Tue, Oct 18, 2016 at 08:59:20PM +0530, Pirate Praveen wrote:
> On Tuesday 18 October 2016 08:27 PM, Lars Wirzenius wrote:
> > This is so wrong, I would like to ask that this package not be allowed
> > into Debian until it's fixed.
> 
> I agree this could be marked RC and stopped from going to a stable
> release. But do we stop accepting new packages in unstable because there
> are serious bugs?

When the bugs are bad enough, I think we should reject the packages
even from unstable, yes.

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


signature.asc
Description: PGP signature

Re: Bug#841196: ITP: node-os-homedir -- Node.js 4 `os.homedir()` ponyfill

[Lars Wirzenius]

On Tue, Oct 18, 2016 at 08:40:49PM +0530, Pirate Praveen wrote:
> I don't particularly enjoy doing this either. Please direct your anger
> at the nodejs developers. I'm doing this only because the packages I
> care (diaspora and gitlab won't be accepted in main, unless I build
> libjs-handlebars and libjs-fuzzaldrin-plus from its source).

Even though I object to this one package (until it's fixed upstream),
I don't want to discourage you from working on this. It's important
work (because diaspora and gitlab are important pieces of free
software). It's unfortunate you get to be the focal point of a lot of
nodejs related anger, some of it unwarranted, and none of it your
fault.

Please keep your spirits high anyway.

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


signature.asc
Description: PGP signature

Re: Bug#841196: ITP: node-os-homedir -- Node.js 4 `os.homedir()` ponyfill

[Adrian Bunk]

On Tue, Oct 18, 2016 at 04:15:50PM +0100, Steve McIntyre wrote:
>...
> Life's too short to go and fix all the crap in the world personally,
> but we can keep certain minimum standards for what we as a group allow
> into Debian. :-(

What policies and processes should ensure these minimum standards?
And who will do the work?

The whole problem is not unique to JS.

See #841113 for a random recent example in C where someone looked
at an ITP.

We are talking about 10 ITPs per day.

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: Bug#841196: ITP: node-os-homedir -- Node.js 4 `os.homedir()` ponyfill

[Jakub Wilk]

* Lars Wirzenius , 2016-10-18, 17:57:

if (process.platform === 'linux') {
return home || (process.getuid() === 0 ? '/root' : (user ? 
'/home/' + user : null));
}

Things are more complicated than that. What exactly is this code meant to be 
used for?


This is so wrong, I would like to ask that this package not be allowed into 
Debian until it's fixed.


The WTFness of this code is certainly way above what we're normally used to, 
but (AIUI) it's only used as a fallback for nodejs < 4. Debian currently has 
4.6.0.


If you assume /root is root's home directory, and it's actually someone else's 
directory, and you trust /root/.ssh/authorized_keys is root's authorized ssh 
keys, you're going to have a bad time.


Er, no. Making /root writable to another user is almost as clever as making 
/bin or /etc writable to others. A sysadmin who does that must be prepared to 
suffer consequences.


--
Jakub Wilk

Re: Bug#841196: ITP: node-os-homedir -- Node.js 4 `os.homedir()` ponyfill

[Steve McIntyre]

Pirate Praveen wrote:
>-=-=-=-=-=-
>
>On Tuesday 18 October 2016 08:45 PM, Steve McIntyre wrote:
>> That doesn't fix (or excuse) poor packaging, though.
>
>Are you saying this is RC? We have different level for bugs, this would
>be wishlist. I don't mind someone writing a better description.

I'd be very surprised if ftpmaster will accept a package with this
level of description, to be honest. Think about users who are trying
to search for packages in Debian - the description is all they have to
go on. I can see you're working on packaging lots of small packages
here, but the extra minute taken to even slightly improve the
packaging like this can't hurt. It's worth it.

>> Life's too short to go and fix all the crap in the world personally,
>> but we can keep certain minimum standards for what we as a group allow
>> into Debian. :-(
>
>But this is something we want in debian (grunt). I don't have to explain
>Free Software model to you. If you find a bug, report it and if you can
>send a patch, please do.

And now you've got me more worried about this lot. I *know* that
you're trying to get up the stack to packaging grunt for the sake of
other packages that need it, and I have a lot of sympathy for your
situation. You have a very big task ahead of you, and I don't envy you
that.

But... Once you've got all these (tiny|awful) lower-level packages
into Debian, are you going to have the time, effort or interest to
follow through and maintain them fully? That means supporting them,
providing security updates, etc. - not just uploading them once to get
your higher-level needs met and then leaving them abandoned.

I'm not suggesting you're a bad person, or anything like that. But I
do understand how hard it can be to maintain a lot of packages well,
and I've seen other people try to do it in the past, and fail. Do you
have many other people who are prepared to help with this project in
the long term?

>It seems there are so many people who focus on stopping other people...

We're not trying to *stop you*. We're worrying about the quality of
Debian here - it's one of our most important goals.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
  Armed with "Valor": "Centurion" represents quality of Discipline,
  Honor, Integrity and Loyalty. Now you don't have to be a Caesar to
  concord the digital world while feeling safe and proud.

Re: Bug#841196: ITP: node-os-homedir -- Node.js 4 `os.homedir()` ponyfill

[Paul Wise]

On Wed, Oct 19, 2016 at 12:03 AM, Jakub Wilk wrote:

> it's only used as a fallback for nodejs < 4. Debian currently has 4.6.0.

Does this mean the ITP can be closed?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Bug#841196: ITP: node-os-homedir -- Node.js 4 `os.homedir()` ponyfill

[Lars Wirzenius]

On Tue, Oct 18, 2016 at 06:03:28PM +0200, Jakub Wilk wrote:
> The WTFness of this code is certainly way above what we're normally used to,
> but (AIUI) it's only used as a fallback for nodejs < 4. Debian currently has
> 4.6.0.

In that case, perhaps this package isn't needed in Debian at all?

> > If you assume /root is root's home directory, and it's actually someone
> > else's directory, and you trust /root/.ssh/authorized_keys is root's
> > authorized ssh keys, you're going to have a bad time.
> 
> Er, no. Making /root writable to another user is almost as clever as making
> /bin or /etc writable to others. A sysadmin who does that must be prepared
> to suffer consequences.

Agreed. Bad example, mea culpa.

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


signature.asc
Description: PGP signature

Re: Bug#820036: No bug mentioning a Debian KEK and booting use it.

[Ian Jackson]

Paul Wise writes ("Re: Bug#820036: No bug mentioning a Debian KEK and booting 
use it."):
> On Tue, Oct 18, 2016 at 7:36 PM, Ian Jackson wrote:
> > I'm afraid I can't make sense of this.  You have posted it to
> > debian-devel, but without any kind of sensible explanation of the
> > context.
> 
> It was posted to bug #820036, which is tracking Debian support for
> secure boot. Peter was advocating quite correctly that as well as
> having our copy of shim (the first-stage bootloader on secure boot
> systems) signed by Microsoft, we should also have a copy signed by a
> Debian signing authority, so that users can theoretically choose to
> distrust the Microsoft key. IIRC, unfortunately in practice that is
> unlikely to be possible since various firmware blobs are only
> Microsoft-signed.

Ah.  Maybe it would be worth doing anyway.  There might be machines
which work with some kind of libre firmware.  But of course actually
doing this depends on someone having the effort.

Anyway, thanks for the explanation.

Ian.

-- 
Ian JacksonThese opinions are my own.

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

Re: Bug#841196: ITP: node-os-homedir -- Node.js 4 `os.homedir()` ponyfill

[Jonas Smedegaard]

Quoting Lars Wirzenius (2016-10-18 17:44:50)
> On Tue, Oct 18, 2016 at 08:59:20PM +0530, Pirate Praveen wrote:
> > On Tuesday 18 October 2016 08:27 PM, Lars Wirzenius wrote:
> > > This is so wrong, I would like to ask that this package not be allowed
> > > into Debian until it's fixed.
> > 
> > I agree this could be marked RC and stopped from going to a stable
> > release. But do we stop accepting new packages in unstable because there
> > are serious bugs?
> 
> When the bugs are bad enough, I think we should reject the packages
> even from unstable, yes.

Use experimental for known-broken packages (if there is reason to 
release at all, e.g. to try avoid burdening NEW queue closer to freeze).

 - 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: Bug#841196: ITP: node-os-homedir -- Node.js 4 `os.homedir()` ponyfill

[Jakub Wilk]

* Lars Wirzenius , 2016-10-18, 19:14:
The WTFness of this code is certainly way above what we're normally used to, 
but (AIUI) it's only used as a fallback for nodejs < 4. Debian currently has 
4.6.0.


In that case, perhaps this package isn't needed in Debian at all?


You would have to patch the depending packages to use os.homedir() directly 
rather than through the wrapper this package provides. But that might be easier 
than surviving the debian-devel discussion. :-P


--
Jakub Wilk

Re: Bug#841196: ITP: node-os-homedir -- Node.js 4 `os.homedir()` ponyfill

[W. Martin Borgert]

Quoting Lars Wirzenius :

Even though I object to this one package (until it's fixed upstream),
I don't want to discourage you from working on this. It's important
work (because diaspora and gitlab are important pieces of free
software). It's unfortunate you get to be the focal point of a lot of
nodejs related anger, some of it unwarranted, and none of it your
fault.

Please keep your spirits high anyway.


+1, as the young people say nowadays.

I really want to see Grunt in Debian as I want to see Diaspora*,
Pump.io, Gitlab etc. and I'm thankful that I don't have to do
the dirty work :~)

Still, the home directory hack is not acceptable. Don't forget
that some downstream distributions such as Ubuntu fetch directly
from unstable.

Just in the unlikely case that upstream were unwilling to fix it,
maybe somebody else can come up with working patch you can use?

Bug#841225: ITP: node-hosted-git-info -- Provides metadata and conversions from repository urls for Github, Bitbucket and Gitlab

[Sruthi Chandran]

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

* Package name: node-hosted-git-info
  Version : 2.1.5
  Upstream Author : Rebecca Turner  (http://re-becca.org)
* URL : https://github.com/npm/hosted-git-info
* License : ISC
  Programming Lang: JavaScript
  Description : Provides metadata and conversions from repository
urls for Github, Bitbucket and Gitlab

Re: Bug#841196: ITP: node-os-homedir -- Node.js 4 `os.homedir()` ponyfill

[Christian Seiler]

On 10/18/2016 05:29 PM, Pirate Praveen wrote:
> On Tuesday 18 October 2016 08:27 PM, Lars Wirzenius wrote:
>> This is so wrong, I would like to ask that this package not be allowed
>> into Debian until it's fixed.
> 
> I agree this could be marked RC and stopped from going to a stable
> release. But do we stop accepting new packages in unstable because there
> are serious bugs?

Well, maintainers should always try to make sure that newly uploaded
packages don't immediately contain RC bugs. That doesn't always work
and I don't think "contains RC bug" should necessarily mean the
package can't go to unstable - but there's a limit, and just because
it's unstable doesn't mean that there shouldn't be at least minimal
standards.

If the package so clearly fails to achieve its _only_ goal as in
this case, I think it's a good idea to delay accepting it into the
archive until it's fixed.

That said, I don't want to discourage you, and to provide something
more productive for the discussion, I'd like to point you to the
following package:

https://github.com/sindresorhus/pwuid

This should help to fix the bug in question. [1]

I'll not say more here, because none of this is really your fault.
Instead I'd like to thank your for all the effort you put into
packaging, and I really am completely in awe of your persistence.
But I do think one of the things that makes Debian great is that
there are some standards that we've come to expect from packaged
software, and this specific package _currently_ just doesn't meet
even the bare minimum standards for unstable - in my opinion. I
hope there's going to be a fixed version of the package soon so it
may enter Debian and you can proceed with the other dependencies.

Regards,
Christian

[1] Funnily enough it's from the same author.

Re: Bug#841196: ITP: node-os-homedir -- Node.js 4 `os.homedir()` ponyfill

[Philipp Kern]

On 10/18/2016 06:28 PM, Jakub Wilk wrote:
> * Lars Wirzenius , 2016-10-18, 19:14:
>>> The WTFness of this code is certainly way above what we're normally
>>> used to, but (AIUI) it's only used as a fallback for nodejs < 4.
>>> Debian currently has 4.6.0.
>> In that case, perhaps this package isn't needed in Debian at all?
> You would have to patch the depending packages to use os.homedir()
> directly rather than through the wrapper this package provides. But that
> might be easier than surviving the debian-devel discussion. :-P

https://www.npmjs.com/package/os-homedir suggests that it is used like this:

  const osHomedir = require('os-homedir');

If we're reaching that point where we are filling in a fallback that is
actually unused because typeof os.homedir === 'function' is true, could
we have a separate package that collects and provides these kind of stubs?

These poly-/ponyfills seem unlikely to ever change their API as well
because they can't, so that should actually be feasible. (I suppose
dependencies are strictly versioned as well and you don't get fixes? Or
packages are renamed anyway when they change API?)

Kind regards
Philipp Kern



signature.asc
Description: OpenPGP digital signature

Re: Bug#841196: ITP: node-os-homedir -- Node.js 4 `os.homedir()` ponyfill

[Pirate Praveen]

On Tuesday 18 October 2016 10:03 PM, Christian Seiler wrote:
> If the package so clearly fails to achieve its _only_ goal as in
> this case, I think it's a good idea to delay accepting it into the
> archive until it's fixed.
> 
> That said, I don't want to discourage you, and to provide something
> more productive for the discussion, I'd like to point you to the
> following package:
> 
> https://github.com/sindresorhus/pwuid

os-homedir is a dependency for expand-tilde and osenv. expand-tilde
already removed its dependency on os-homedir.

I have asked author of resolve-dir to use the expand-tilde which does
not depend on older os-homedir [1]. But we should be fine to use
expand-tilde 2.0 directly, I think.

[1] https://github.com/jonschlinkert/resolve-dir/issues/2

I have also asked osenv author to remove the dependency [2]

[2] https://github.com/npm/osenv/issues/11

If they are not doing it, I'll patch these and we can remove
node-os-homedir.




signature.asc
Description: OpenPGP digital signature

Re: node-os-homedir_1.0.2-1_amd64.changes is NEW

[Pirate Praveen]

On Tuesday 18 October 2016 11:00 PM, Debian FTP Masters wrote:
> binary:node-os-homedir is NEW.
> source:node-os-homedir is NEW.
> 
> Your package has been put into the NEW queue, which requires manual action
> from the ftpteam to process. The upload was otherwise valid (it had a good
> OpenPGP signature and file hashes are valid), so please be patient.

please reject this package. See
https://lists.debian.org/debian-devel/2016/10/msg00433.html

We can patch resolve-dir to use a newer version of expand-tilde which no
longer use os-homedir module.

older version of osenv module does not depend on os-homedir.

> Packages are routinely processed through to the archive, and do feel
> free to browse the NEW queue[1].
> 
> If there is an issue with the upload, you will receive an email from a
> member of the ftpteam.
> 
> If you have any questions, you may reply to this email.
> 
> [1]: https://ftp-master.debian.org/new.html
> 




signature.asc
Description: OpenPGP digital signature

Re: Is missing SysV-init support a bug?

[Xen]

Not subscribed so this will break threading.


On 2016-10-17 at 17:53, Bart Schouten wrote:



I would consider that bigotry as SystemD is short pretty much for
System Daemon.



While this is a reasonable point, it doesn't invalidate Nikolas' point:
that the people behind the systemd project A: do not consider it to be
spelled that way (and, yes, capitalization is part of correct spelling,
at least when it comes to names), B: are likely to perceive the refusal
to spell it in the way which they see as correct to be a sign of
hostility, and C: are likely to react accordingly to that perceived
hostility.


If that is the case then they have enbedded hostility into their name 
simply becaus eit offends normal grammar roles.


If ou are ygoing to name your son "john" and then insist that everyone 
write your name in lowercase, you are going to have issues.


*every software out there is going to capitazlize the first letter
*people all over will refuse to write it with a lowercase only.

*proper names (proper nouns) are written by default in our languages 
with an upeer case initial latter. This breaks grammaticasl rules and 
idiomatic rules.


I mean, what is the intent here? To stir up trouble reagrdless?

You can claim that I am the deviant here, but that is not so. These 
authors apparently willingly disrupt natural language flow in a language 
that has upper case and lower case letters. What about German? Even 
regular nouns are capitalized and you want to write it with lowercase.


Apparently Lennart Poettering himself wants the name to be lowercased 
(he wrote the section on the webpage himself, he told me) (that 
references the spellin0 but with all due respect, your language skills 
completely suck if youinsist on writing it lowercased even when writing 
text athat is supposed to be flowing prose.


It's really cute if you can use monomspaced font in your text when all 
the rest is sans-serif, you know, so it doesn't trouble you so much, but 
these are emails.


We have no markup here, it is all monospace, or whatever you ahve.

I mean Lennart is a nice guy when you respond nicely to him and it is 
pretty nice to talk to him but this is not about him, he doesn't need to 
write the words that I use, nor are you by definition "his people", itś 
as if we are now no longer allowed *anywhere* to write it the way we 
want, another dictatorship? If it concerns him (or his team, fine). 
Whyshould it concern me the rest of the time?


I should suffer unreadable text because Lennart or someone else has a 
pecularity about it? I rather doubt he is a guy like that, you know, 
that we would care what other epople do at the other side of the 
universie, to him.


But more importantly it makes me question the validity of the Debian 
project if it identifies with SystemD so much that IT becomes hostile 
when the name of its components (or one of its components, I was meaning 
to write) is written in the "wrong" way. That means you are no longer 
independent people and that's what worries me.



Without taking sides on the question at hand: do you, then, spell the
name of the distribution as DebIan?


Is that the most reasonable capitalisation of that name?

I didn't even know what it stood for, I must say.

But you know full well that people would tire of writing DebIan within a 
minute, and coincidentally, Debian is the propr form of a proper noun in 
our language. Most words that are written as ca combination of two tend 
to become a single noun: Facebook, Wikipedia, it is way too annoying to 
write it with two capitals. Midway, at least.


But Systemd is not a word, and System is a word, and it stands to reason 
that you would write either systemd or SystemD. Nothing else makes 
sense. So then if you need to use capitals to make the text stand out 
more you use SystemD just like SystemV (or System V) used to be writen. 
This stands to reason. *I* can't help it that the name conflicts with 
and offends natural language as we write it. *I* can't hep it that the 
name interferes with normal grammatical rules. I did not choose the 
name, why should I suffer for it?


And I think it is just pretty change if you would go so far as to make 
this a point of contention which makes me feel you have other issues.


Mister the Wanderer, maybe your signature is meaningful here ;-). Or at 
least, reasonable ;-0).


By the way, again people manage to make a mountain out of a molehill 
which means to me they really have nothing better to do than this and it 
maens to me they are wasting their time on what they *are* doing.

Re: When should we https our mirrors?

[Robert Edmonds]

Tollef Fog Heen wrote:
> ]] Paul Tagliamonte 
> 
> > So, when are we going to push this? If not now, what criteria need to
> > be met? Why can't we https-ify the default CDN mirror today?
> 
> The usual crypto answer: because key handling is hard.
> 
> Doing this for the per-country mirrors means that repointing mirrors
> becomes a lot harder than it currently is, and this is something we do
> on a daily basis.  We'd need a solution for deploying the TLS cert for,
> say, ftp.de.d.o to ftp.se.d.o (or ftp.d.o) if ftp.d.o is down for
> maintenance.
> 
> Doing this for deb.d.o would mean we need to get certs on both Fastly
> and Cloudfront deployed, which is, frankly, a more realistic proposition
> than jury-rigging something on the per-country mirrors.

Hi,

Since the Debian project controls the mirror client (in particular the
code responsible for performing certificate validation), surely there is
some way we can engineer our way to a less painful solution? We don't
have to imitate the way web browsers or other HTTP clients perform
certificate validation, right?

We currently use DNS SRV records for a few mirror domains to direct apt
traffic, e.g. for ftp.us.debian.org:

;; QUESTION SECTION:
;_http._tcp.ftp.us.debian.org. IN SRV

;; ANSWER SECTION:
_http._tcp.ftp.us.debian.org. 3600 IN SRV 0 1 80 ftp-chi.osuosl.org.
_http._tcp.ftp.us.debian.org. 3600 IN SRV 0 2 80 ftp-nyc.osuosl.org.
_http._tcp.ftp.us.debian.org. 3600 IN SRV 0 1 80 debian.gtisc.gatech.edu.

If there were some way to be able to trust the SRV target names (the
right-most names in the above output like "debian.gtisc.gatech.edu",
which tend to be very stable since they're chosen by the mirror
operator), we could use those names as the domain name in the TLS
certificate to be validated by apt, and it would be easy for a mirror
operator to go off and acquire a TLS certificate for the "canonical"
name of their server, rather than the .debian.org alias. Unfortunately,
the data in the SRV records comes from the DNS, and even though the
debian.org zone is signed, we cannot currently rely on DNSSEC validation
occurring (and occurring successfully) on every Debian system running
apt.

Some possibilities:

1)

Maybe we could securely distribute the list of canonical mirror names
via security.debian.org (using traditional certificate validation
rules), either in a package or in metadata stored in the archive?

2)

Maybe we could constrain apt so that it would use the (untrusted) DNS
SRV target names for certificate validation only if the names were
rooted in a base domain name on a whitelist? E.g., if the SRV target
name ends in "._tls-servers.debian.org", then that name can be used as
the name to be validated in the TLS certificate. Then we could set up
SRV RRs that use aliased mirror hostnames like this:

_https._tcp.ftp.us.debian.org. SRV 0 1 443 
ftp-chi.osuosl.org._tls-servers.debian.org.
_https._tcp.ftp.us.debian.org. SRV 0 2 443 
ftp-nyc.osuosl.org._tls-servers.debian.org.
_https._tcp.ftp.us.debian.org. SRV 0 1 443 
debian.gtisc.gatech.edu._tls-servers.debian.org.

and then alias those target names to the canonical mirror hostnames:

ftp-chi.osuosl.org._tls-servers.debian.org. CNAME ftp-chi.osuosl.org.
ftp-nyc.osuosl.org._tls-servers.debian.org. CNAME ftp-nyc.osuosl.org.
debian.gtisc.gatech.edu._tls-servers.debian.org. CNAME debian.gtisc.gatech.edu.

Then the operator of debian.gtisc.gatech.edu only has to go off and set
up a vhost for "debian.gtisc.gatech.edu._tls-servers.debian.org" in the
mirror server's HTTP config, and acquire a TLS certificate for that
name.


Both of these options have the problem that a potential MITM can just
become a rogue mirror operator, but perhaps more fine-grained
constraints could be defined, or we could require the same level of
trust for HTTPS mirror operators that we do for new maintainers (i.e.,
PGP signatures from two active developers)?

-- 
Robert Edmonds
edmo...@debian.org

Re: Is missing SysV-init support a bug?

[Lars Wirzenius]

On Tue, Oct 18, 2016 at 07:34:28PM +0200, Xen wrote:
> If that is the case then they have enbedded hostility into their name simply
> becaus eit offends normal grammar roles.

I don't that's it at all.

The reason many people react to the SystemD spelling is becuase, for
some years now, trolls use that spelling when harrassing others about
systemd.

Calling it SystemD indicates to many people that you're the kind of
person show turns up from nowhere, and starts spreading fear,
uncertainty, and doubt about systemd, or presenting conspiracy
theories about it, or making ad hominem attacks on its authors. People
with bad experiences from previous systemd discussions will assume
you're that kind of troll, regardless of the value of any of your
claims or statements may have. Or at least I do.

We've had systemd related discussions for years. Just about every real
or imaginable problem with systemd has been raised. Even so, we chose
it as the default init in Debian, while keeping support for other
inits, and those railing against this are just not worth arguing with
anymore.

Those who report actionable issues in systemd, or in our support for
other init systems, are welcome and should get all due attention. Bugs
are bugs and bugs should be squashed.

Everything in this mail is my personal opinion. It's possible other
members of the community working on Debian have different opinions.

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


signature.asc
Description: PGP signature

Re: When should we https our mirrors?

[Marco d'Itri]

On Oct 17, Ian Campbell  wrote:

> Have we gotten to the point where we consider deb.d.o suitable for
> production use? The web page still says Experimental (so I would assume
I do not think that it is appropriate for general use, since at least 
one of the CDNs backing it lacks nodes in many (most) countries.
I like to get my Debian packages over peering links. :-)

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: [pkg-gnupg-maint] Bug#840669: Bug#840669: Beware of leftover gpg-agent processes

[Daniel Kahn Gillmor]

On Tue 2016-10-18 07:44:43 -0400, Ian Jackson wrote:
> Daniel Kahn Gillmor writes ("Re: [pkg-gnupg-maint] Bug#840669: Bug#840669: 
> Beware of leftover gpg-agent processes"):
>> On Sat 2016-10-15 11:21:29 -0400, Ian Jackson wrote:
>> > 1. gnupg1-compatible authorisation lifetime:
>> 
>> I believe this is a deliberate change in semantics from the upstream
>> GnuPG project.  In particular, authorization for the use of secret key
>> material is now the responsibility of the gpg-agent.  This is an overall
>> win, because it means that no process ever gets access to the secret key
>> in memory *except* for the gpg-agent.
>
> I think these properties about key material handling are good, but
> this is not the same question as the authorisation lifetime.  You are
> conflating two separate things.

I agree that these are distinct choices, but their implementation
details are closely linked.

>>  The gpg-agent is where these decisions are made.
>
> Actually, though, it just acts as an oracle, so it does not make any
> decisions.

It is making a decision about whether to grant use of a given key.  For
example, it's possible to ask gpg-agent to prompt the user to confirm
the use of any ssh-capable key.  (i'm unaware of how to ask it for user
confirmation for other, non-ssh keys, though)

If the current decision-making policy language isn't descriptive enough
for your goals, we should clarify what those goals are and try to figure
out a way that you can express them to the agent.  That's distinct from 

>> If you want an agent that never caches any passphrase (and therefore has
>> a one-use-per-authorization), this is an easy thing to do by adjusting
>> max-cache-ttl in gpg-agent.conf.  you can also set this dynamically with
>> gpgconf (see the --runtime option in gpgconf(1)).
>
> It sounds like this is very close to what I want for the authorisation
> lifetime qeustion (provided that it isn't racy).  Why is this not the
> default for command line users without a session-provided agent ?

I think the goal is to provide uniform behavior, regardless of whether
the agent is session-provided or otherwise, instead of having a subtle
difference between an auto-launched agent and an explicitly-initialized
agent.  Perhaps Werner can speak more to this decision, though.

 --dkg


signature.asc
Description: PGP signature

Re: [Pkg-dns-devel] Bug#833309: "Browserified" stuff (knot-resolver-module-http: please package embedded epoch.js separately)

[Joerg Jaspert]

>> On 14458 March 1977, W. Martin Borgert wrote:
>> > If I package a compiler and put y.tab.c in the package, drop
>> > grammar.y in d/m-s/, would it be OK or not?
>> If you come up with a good reason for it, yes. But I doubt you would
>> find one here.
> Let's say I need a special tool to compile it, e.g.
> bison-priscus, and I don't want to package it for Debian?

Seriously, the question in this thread? Where the initial mail is the
answer of the question?

>> > If I don't even check that bison actually can process the file, would
>> > it still be OK?
>> No.
>> You as the maintainer have to guarantee that the file is buildable with
>> tools available in main. You can't if you don't ever check this.
> IIUC, this is exactly the situation of epoch.js in
> knot-resolver-module-http. I assume, it has not been build from
> its original *.coffee sources, because the make tool (gulp) is
> not in Debian. So the package must go into contrib?

Yes, thats what contrib is for. "require stuff outside main to build or
function".

-- 
bye, Joerg

Re: Is missing SysV-init support a bug?

[Cameron Norman]

On Tue, Oct 18, 2016 at 11:23 AM, Lars Wirzenius  wrote:
> On Tue, Oct 18, 2016 at 07:34:28PM +0200, Xen wrote:
>> If that is the case then they have enbedded hostility into their name simply
>> becaus eit offends normal grammar roles.
>
> I don't that's it at all.
>
> The reason many people react to the SystemD spelling is becuase, for
> some years now, trolls use that spelling when harrassing others about
> systemd.
>
> Calling it SystemD indicates to many people that you're the kind of
> person show turns up from nowhere, and starts spreading fear,
> uncertainty, and doubt about systemd, or presenting conspiracy
> theories about it, or making ad hominem attacks on its authors. People
> with bad experiences from previous systemd discussions will assume
> you're that kind of troll, regardless of the value of any of your
> claims or statements may have. Or at least I do.

Those reading so much into such a small and understandable
capitalization mistake (SystemV -> SystemD) should learn to take
themselves less seriously and view things from different perspectives.

Re: Is missing SysV-init support a bug?

[Nikolaus Rath]

On Oct 18 2016, Cameron Norman  wrote:
> On Tue, Oct 18, 2016 at 11:23 AM, Lars Wirzenius  wrote:
>> On Tue, Oct 18, 2016 at 07:34:28PM +0200, Xen wrote:
>>> If that is the case then they have enbedded hostility into their name simply
>>> becaus eit offends normal grammar roles.
>>
>> I don't that's it at all.
>>
>> The reason many people react to the SystemD spelling is becuase, for
>> some years now, trolls use that spelling when harrassing others about
>> systemd.
>>
>> Calling it SystemD indicates to many people that you're the kind of
>> person show turns up from nowhere, and starts spreading fear,
>> uncertainty, and doubt about systemd, or presenting conspiracy
>> theories about it, or making ad hominem attacks on its authors. People
>> with bad experiences from previous systemd discussions will assume
>> you're that kind of troll, regardless of the value of any of your
>> claims or statements may have. Or at least I do.
>
> Those reading so much into such a small and understandable
> capitalization mistake (SystemV -> SystemD)

It doesn't matter if the difference is small or big. What matters is
that in the past this difference has been an excellent predictor of
everything else the author has to say. It's rare that one can draw so
much information out of so little data, so I don't think its reasonable
to expect people to stop relying on it.


Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«

Re: Is missing SysV-init support a bug?

[Russ Allbery]

Cameron Norman  writes:

> Those reading so much into such a small and understandable
> capitalization mistake (SystemV -> SystemD) should learn to take
> themselves less seriously and view things from different perspectives.

You will find that when you point out the correct spelling to those who
use this one, the response is not "oh, whoops," like it would be for a
mistake.  Rather, it's usually a rant of surprising vitriol, a bunch of
bizarrely constructed justifications for why their spelling is correct,
and an insistence on continuing to use it.  You can see that happen on
this very thread.

That means "mistake" is clearly not the correct term.

I find the correct term a bit mysterious, partly because I don't
understand the impulse, but I suspect it's much closer to "dog-whistle"
[1] or "tribal marker" than "mistake."

The reactions of others is not about the spelling difference, which is
obviously trivial.  It's about the refusal to change, the insistence on
mislabeling something, and the surprising anger and oddly twisted defenses
that ensue afterwards, making it clear that this is a marker of something
much deeper and much darker than just a trivial mistake.

[1] https://en.wikipedia.org/wiki/Dog-whistle_politics for those
unfamiliar with this term.

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

Re: Is missing SysV-init support a bug?

[Steve Langasek]

On Tue, Oct 18, 2016 at 08:11:21PM -0700, Russ Allbery wrote:
> You will find that when you point out the correct spelling to those who
> use this one, the response is not "oh, whoops," like it would be for a
> mistake.  Rather, it's usually a rant of surprising vitriol, a bunch of
> bizarrely constructed justifications for why their spelling is correct,
> and an insistence on continuing to use it.  You can see that happen on
> this very thread.

> That means "mistake" is clearly not the correct term.

> I find the correct term a bit mysterious, partly because I don't
> understand the impulse, but I suspect it's much closer to "dog-whistle"
> [1] or "tribal marker" than "mistake."

> The reactions of others is not about the spelling difference, which is
> obviously trivial.  It's about the refusal to change, the insistence on
> mislabeling something, and the surprising anger and oddly twisted defenses
> that ensue afterwards, making it clear that this is a marker of something
> much deeper and much darker than just a trivial mistake.

So... a shibboleth. ;)

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature