Bug#864622: RFS: rich-minority/1.0.1-1 [ITP]
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
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]
>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]
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]
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