Re: Proposed change of offensive packages to -offensive

[Russ Allbery]

Holger Levsen  writes:
> On Tue, Nov 21, 2017 at 02:56:36PM -0700, Sean Whitton wrote:

>>> Not involved in any of the packages, but I guess that whatever
>>> agreement we make it is worth documenting elsewhere apart of the
>>> mailing list archive.  Wiki? policy?

>> Policy.

> no, please, no.

> policy should document technical terms.

> whatever else we might come up to deal with the "real world" (that is
> more complicated than that, eg think tibet, taiwan and china, or $foo)
> should not be included in -policy.

> what's offensive to you, might be my everyday. IOW: what's offensive to
> you (or me) might be my|your everyday.

Policy in this case would document the convention of using -offensive for
packages that are split along those lines *by the maintainer*.  I agree
that we certainly shouldn't attempt to define what is and isn't offensive
in Policy and leave that up to the maintainer.  But it sounds like we have
a package naming convention for this specific type of package split, and
the standardization of the naming convention (-offensive instead of -off
or -dirty or -nsfw or whatever other thing someone might come up with) is
within the traditional grounds of Policy.

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

Re: Proposed change of offensive packages to -offensive

[Holger Levsen]

On Tue, Nov 21, 2017 at 02:56:36PM -0700, Sean Whitton wrote:
> > Not involved in any of the packages, but I guess that whatever
> > agreement we make it is worth documenting elsewhere apart of the
> > mailing list archive.  Wiki? policy?
> Policy.

no, please, no.

policy should document technical terms.

whatever else we might come up to deal with the "real world" (that is
more complicated than that, eg think tibet, taiwan and china, or $foo)
should not be included in -policy.

what's offensive to you, might be my everyday. IOW: what's offensive to
you (or me) might be my|your everyday.


-- 
cheers,
Holger


signature.asc
Description: PGP signature

Re: Proposed change of offensive packages to -offensive

[Sean Whitton]

Hello,

On Tue, Nov 21 2017, Arturo Borrero Gonzalez wrote:

> I agree.

Me too.  I was not aware of the -off convention, and couldn't have
guessed it.

> Not involved in any of the packages, but I guess that whatever
> agreement we make it is worth documenting elsewhere apart of the
> mailing list archive.  Wiki? policy?

Policy.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#882374: ITP: python-fpdf2 -- Minimalist PDF creation library for Python

[Ondrej Tuma]

Package: wnpp
Severity: wishlist
Owner: Ondrej Tuma 

* Package name: python-fpdf2
  Version : 2.0.0
  Upstream Author : David Ankin 
* URL : https://github.com/alexanderankin/pyfpdf
* License : LGPL
  Programming Lang: Python
  Description : Minimalist PDF creation library for Python

PyFPDF is a library for PDF document generation under Python, ported from PHP
(see FPDF: "Free"-PDF, a well-known PDFlib-extension replacement with many
examples, scripts and derivatives).

Compared with other PDF libraries, PyFPDF is simple, small and versatile, with
advanced capabilities, and is easy to learn, extend and maintain.

This library could be use in more other python applications. Maintainer could
be DPMT.

Re: Proposed change of offensive packages to -offensive

[Arturo Borrero Gonzalez]

On 21 November 2017 at 14:01, Ian Jackson
 wrote:
> We have an (AFAICT informal) convention that packages with offensive
> content, or content in questionable taste, should have names ending in
> -off.  This abbreviation is unnecessary, and increases the chances
> that someone will install such a thing by mistake.
>
> (If cowsay-off had been called cowsay-offensive, #882085 would
> probably have been discovered rather sooner and in a rather better
> way.)
>
> I would like to suggest that we rename all such packages to
> "foo-offensive" for buster.  (Also, the highest dependency on such a
> package from a non-"-offensive" package should be Suggests.)
>
> AFAICT 3 packages are affected: fortunes (and its translations),
> cowsay, and purity.
>

I agree.

Not involved in any of the packages, but I guess that whatever
agreement we make it is worth documenting elsewhere apart of the
mailing list archive.
Wiki? policy?

Proposed change of offensive packages to -offensive

[Ian Jackson]

We have an (AFAICT informal) convention that packages with offensive
content, or content in questionable taste, should have names ending in
-off.  This abbreviation is unnecessary, and increases the chances
that someone will install such a thing by mistake.

(If cowsay-off had been called cowsay-offensive, #882085 would
probably have been discovered rather sooner and in a rather better
way.)

I would like to suggest that we rename all such packages to
"foo-offensive" for buster.  (Also, the highest dependency on such a
package from a non-"-offensive" package should be Suggests.)

AFAICT 3 packages are affected: fortunes (and its translations),
cowsay, and purity.

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.

Bug#882343: general: Laptop crashing after suspend if device is plugged into headphone jack

[bugreporter41]

Package: general
Severity: important

Dear Maintainer,


Laptop crashes if headphone device is left in when resume from suspend is
attempted or if it is suspended then taken out then resumed.




-- System Information:
Debian Release: 9.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#882301: ITP: r-cran-ddalpha -- GNU R depth-based classification and calculation of data depth

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: r-cran-ddalpha
  Version : 1.3.1
  Upstream Author : Oleksii Pokotylo 
* URL : https://cran.r-project.org/package=ddalpha
* License : GPL
  Programming Lang: GNU R
  Description : GNU R depth-based classification and calculation of data 
depth
 Contains procedures for depth-based supervised learning, which are
 entirely non-parametric, in particular the DDalpha-procedure (Lange,
 Mosler and Mozharovskyi, 2014). The training data sample is transformed
 by a statistical depth function to a compact low-dimensional space,
 where the final classification is done. It also offers an extension to
 functional data and routines for calculating certain notions of
 statistical depth functions. 50 multivariate and 5 functional
 classification problems are included.


Remark: This package belongs to a pyramid of dependencies to upgrade
r-cran-caret to its latest upstream version.  It will be maintained by
the Debian Science team at
https://anonscm.debian.org/git/debian-science/packages/r-cran-ddalpha.git
Any takers for other new dependencies of r-cran-caret would be
really appreciated.  Also other Uploaders who volunteer to keep on
maintaining the packages are really welcome.

Bug#882300: ITP: neomutt -- A command line mail reader (or MUA). It's a version of Mutt with added features.

[Antonio Radici]

Package: wnpp
Severity: wishlist
Owner: anto...@debian.org

* Package name: neomutt
  Version : 1.9.1+20171027
  Upstream Author : Richard Russon 
* URL : http://www.neomutt.org
* License : GPLv2
  Programming Lang: C
  Description : NeoMutt is a command line mail reader (or MUA). It's a 
version of Mutt with added features.


To give more context, have a look at b/870635; neomutt was packaged as 'mutt' in
stretch but the current mutt maintainer has raised issue of the tarball being
used: since the codebase of neomutt diverged (initially due to code formatting
changes, then due to some API changes and code split), which made patching mutt
with a single huge neomutt patch impractical (the patch was larger than the
source code).

We have restored original mutt source code at version 1.9.1-1 and given that
this was just done, I plan to spin up a new neomutt package starting from the
same version (with the latest version of neomutt); the plan is to fork the
pkg-mutt git repository from the latest tag and start from there, packaging the
new neomutt version.