Bug#864622: RFS: rich-minority/1.0.1-1 [ITP]

[Nicholas D Steeves]

Hi Sean,

On Tue, Jun 13, 2017 at 06:42:28PM +0100, Sean Whitton wrote:
> Hello Nicholas,
> 
> On Mon, Jun 12, 2017 at 07:33:12PM -0400, Nicholas D Steeves wrote:
> > Would it be better to ship README.org and file a bug against the
> > package myself?
> 
> Yes.  Why not ship README.org in the interim?

Let's discuss .org documentation at DebConf.  I've converted the
README to plaintext for now.

> > How many lines can I dedicate to this?  By my count I need to
> > summarise the following in five lines, and the most salient additions
> > are the mention of diminish.el, plus compare/contrast by adding what I
> > suspect are the two most salient points.
> >   * "/missing/...quick and simple replacement functionality"
> >   * the addition of "It accepts *regexps* instead of [individual 
> > specifications]".
> 
> Where are you getting this line limit from?

In the same way that lines must be hard-wrapped to fit a 80 column
terminal I inferred that long description should also fit in a 24 line
terminal, and that README should used for anything longer.  Maybe it's
not a hard rule, but this has always struck me as a sort of standard.
At any rate, I've updated the description.

> > These two points seem contradictory to me.  Do you know how
> > diminish.el is more quick and simple?  Also, can I use your answer for
> > a patch against the upstream description, because I might not be the
> > only one who's not confused about this.  Failing that, I can open an
> > upstream issue/request for clarified description.
> 
> diminish.el works like this:
> 
> (diminish 'auto-fill-function)
> 
> That's it.  Clearly simpler.

I think this is probably the simplest rich-minority-mode equivalent,
assuming that subsequent (diminish 'minor-mode-function) adds items
to-be-hidden:

(push " Fill" rm-blacklist)

I haven't investigated corner cases, but it would seem that
rich-minority-mode might also be simple :-)

All of your comments should be addressed by 419b8ca which I believe is
ready to upload.  I would be very appreciative if you would also grand
DM permissions for it :-)

Thank you,
Nicholas


signature.asc
Description: Digital signature

Bug#867617: RFS/ITP: node-rollup-plugin-replace/1.1.1-1

[Julien Puydt]

Package: sponsorship-requests
Severity: wishlist

  Dear mentors,

  I am looking for a sponsor for my package "node-rollup-plugin-replace"

 * Package name: node-rollup-plugin-replace
   Version : 1.1.1-1
   Upstream Author : Rich Harris
 * URL : https://github.com/rollup/rollup-plugin-replace
 * License : Expat
   Section : web

  It builds those binary packages:

node-rollup-plugin-replace - Rollup plugin to make string
substitutions while bundling

  To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/node-rollup-plugin-replace


  Alternatively, one can download the package with dget using this command:

dget -x
https://mentors.debian.net/debian/pool/main/n/node-rollup-plugin-replace/node-rollup-plugin-replace_1.1.1-1.dsc

  It is packaged within the Debian JavaScript Maintainers team:

Vcs-Git:
https://anonscm.debian.org/git/pkg-javascript/node-rollup-plugin-replace.git
Vcs-Browser:
https://anonscm.debian.org/cgit/pkg-javascript/node-rollup-plugin-replace.git

 Thanks,

Snark on #debian-js

Bug#862930: RFS: node-big-integer/1.6.22-1 [ITP]

[Gianfranco Costamagna]

>I'm not sure what you mean.
>These are dev dependencies, they are used by big-integer developers to 
>perform various development tasks, but they are not required to simply 
>use the library so there is no point in packaging them in Debian.
>And they are *not* embedded in the package, they only appear in 
>package.json.


this makes sense, thanks.
So the review goes to the next step.
1) licenses are missing (even if not used in the binary package, the copyright
should list all the licenses in the source code).
2) please use the same copyright as upstream for Debian packaging, this will 
make
patch upstreaming possible without having to explicitly relicense them

thanks

G.

Bug#862930: RFS: node-big-integer/1.6.22-1 [ITP]

[Pierre Rudloff]

Le 07/07/2017 à 08:50, Gianfranco Costamagna a écrit :

control: owner -1 !
control: tags -1 moreinfo

I am looking for a sponsor for my package "node-big-integer"



"devDependencies": {
"coveralls": "^2.11.4",
"jasmine": "2.1.x",
"jasmine-core": "^2.3.4",
"karma": "^0.13.3",
"karma-coverage": "^0.4.2",
"karma-jasmine": "^0.3.6",
"karma-phantomjs-launcher": "~0.1",
"uglifyjs": "^2.4.10"
},


I think you should package the dependencies separately.
Using embedded library is something we should avoid whenever possible.

Do you want to give a look at them before trying to package this one?

G.



Hello,

I'm not sure what you mean.
These are dev dependencies, they are used by big-integer developers to 
perform various development tasks, but they are not required to simply 
use the library so there is no point in packaging them in Debian.
And they are *not* embedded in the package, they only appear in 
package.json.


Regards,

Bug#867544: RFS: golang-github-xiaq-persistent/0.0~git20170614.0.06adb7b-1 [ITP]

[Shengjing Zhu]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "golang-github-xiaq-persistent"

* Package name: golang-github-xiaq-persistent
  Version : 0.0~git20170614.0.06adb7b-1
  Upstream Author : Qi Xiao 
* URL : https://github.com/xiaq/persistent
* License : Eclipse Public License 1.0
  Section : devel

It builds those binary packages:

  golang-github-xiaq-persistent-dev - Persistent data structure in Go

To access further information about this package, please visit the following 
URL:

https://mentors.debian.net/package/golang-github-xiaq-persistent


Alternatively, one can download the package with dget using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/g/golang-github-xiaq-persistent/golang-github-xiaq-persistent_0.0~git20170614.0.06adb7b-1.dsc

The repository of this package is at:

https://anonscm.debian.org/cgit/pkg-go/packages/golang-github-xiaq-persistent.git

Changes since the last upload:

* Initial release (Closes: #867525)

Regards,
Shengjing Zhu


signature.asc
Description: PGP signature

Bug#862930: RFS: node-big-integer/1.6.22-1 [ITP]

[Gianfranco Costamagna]

control: owner -1 !
control: tags -1 moreinfo
>I am looking for a sponsor for my package "node-big-integer"


"devDependencies": {
"coveralls": "^2.11.4",
"jasmine": "2.1.x",
"jasmine-core": "^2.3.4",
"karma": "^0.13.3",
"karma-coverage": "^0.4.2",
"karma-jasmine": "^0.3.6",
"karma-phantomjs-launcher": "~0.1",
"uglifyjs": "^2.4.10"
},


I think you should package the dependencies separately.
Using embedded library is something we should avoid whenever possible.

Do you want to give a look at them before trying to package this one?

G.