Re: Code in Description [Was: Re: node-tty-browserify_0.0.0-1_amd64.changes REJECTED]
On Sat, 11 Feb 2017, Pirate Praveen wrote:
> On വെള്ളി 10 ഫെബ്രുവരി 2017 09:36 വൈകു, Don Armstrong wrote:
> > I wonder if this was a case of the code not being sufficient
> > description? [IE, code and a good text description would be accepted,
> > but code only was not?]
>
> These packages were rejected and their description is given below.
[...]
> https://anonscm.debian.org/cgit/pkg-javascript/node-pretty-bytes.git/tree/debian/control?id=5d128d8a7a60cc629e7d5fa857d4be4a43bf031e
Description: Node.js library which converts bytes to larger units (kB)
This component of Node.js implements a suite of functions which
converts bytes to larger si units with rounding. You are
unlikely to want to install this library by itself.
.
For example, 1337 is converted to 1.34kB
.
Node.js is an event-based server-side JavaScript engine.
> 2. node-is-obj:
> http://lists.alioth.debian.org/pipermail/pkg-javascript-devel/2017-January/017568.html
[...]
> https://anonscm.debian.org/cgit/pkg-javascript/node-is-obj.git/tree/debian/control?id=574546f8018c8f6db7d3155b5b510448aacafca5
Description: Node.js library which implements a test of an object-ness
This component of Node.js implements a function "isObj" which tests
whether its argument is an object or not. You are unlikely to want to
install this package by itself.
.
const isObj = require('is-obj');
isObj({foo: 'bar'}); // true
isObj([1, 2, 3]); // true
isObj('foo'); // false
.
Node.js is an event-based server-side JavaScript engine.
For example.
--
Don Armstrong https://www.donarmstrong.com
I would like to be the air
that inhabits you for a moment
only. I would like to be that unnoticed
& that necessary.
-- Margaret Atwood "Poetry in Motion" p140
Bug#854920: ITP: python-pyflow -- lightweight parallel task engine for Python
Package: wnpp Severity: wishlist Owner: Andreas Tille * Package name: python-pyflow Version : 1.1.14 Upstream Author : Illumina, Inc. * URL : https://illumina.github.io/pyflow/ * License : BSD Programming Lang: Python Description : lightweight parallel task engine for Python pyFlow is a tool to manage tasks in the context of a task dependency graph. It has some similarities to make. pyFlow is not a program – it is a Python module, and workflows are defined using pyFlow by writing regular Python code with the pyFlow API. Remark: This Python module is needed to package manta[1]. It will be maintained by the Debian Med team at https://anonscm.debian.org/git/debian-med/python-pyflow.git [1] https://github.com/Illumina/manta https://anonscm.debian.org/git/debian-med/manta.git
Bug#854917: ITP: empty-epsilon -- EmptyEpsilon is a spaceship bridge simulator game
Package: wnpp Severity: wishlist Owner: Kyle Robbertze * Package name: empty-epsilon Version : 2017.01.19 Upstream Author : daid * URL : https://daid.github.io/EmptyEpsilon * License : Expat Programming Lang: C++ Description : EmptyEpsilon is a spaceship bridge simulator game EmptyEpsilon places you in the roles of a spaceship's bridge officers. While you can play EmptyEpsilon alone or with friends, the best experience involves 6 players working together on each ship. Each officer fills a unique role: Captain, Helms, Weapons, Relay, Science, and Engineering. Except for the Captain, each officer operates part of the ship through a specialized screen. The Captain relies on their trusty crew to report information and follow orders.
Bug#854916: ITP: seriousproton -- C++ game engine coded on top of SFML from scratch
Package: wnpp Severity: wishlist Owner: Kyle Robbertze * Package name: seriousproton Version : 2017.01.19 Upstream Author : daid * URL : https://github.com/daid/SeriousProton * License : Expat Programming Lang: C++ Description : C++ game engine coded on top of SFML from scratch SeriousProton is a game engine library. It includes a multiplayer server and game engine largely targeted at two dimensional space combat. Programmers can use it in their games to simulate 2D space combat, for example as if it is laying out through a radar view. SeriousProton is a dependency of empty-epsilon, which is a spaceship bridge simulation game.
Bug#854904: ITP: emacs-git-messenger -- pop up last commit information of current line
Package: wnpp Severity: wishlist Owner: Lev Lamberov * Package name: emacs-git-messenger Version : 0.18 Upstream Author : Syohei Yoshida * URL : https://github.com/syohex/emacs-git-messenger * License : GPL-3+ Programming Lang: Emacs Lisp Description : pop up last commit information of current line This package provides a function that when called will pop-up the last git commit message for the current line. This is useful when you want to know why this line was changed. This uses the git-blame tool internally.
Bug#854903: ITP: node-anymatch -- Matches strings against configurable strings, globs, regular expressions, and/or functions
Package: wnpp Severity: wishlist Owner: Aarti Kashyap X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-anymatch Version : 1.3.0 Upstream Author : Elan Shanker (http://github.com/es128) * URL : https://github.com/es128/anymatch * License : ISC Programming Lang: JavaScript Description : Matches strings against configurable strings, globs, regular expressions, and/or functions It is a dependency for ava,a futuristic test-runner . Node.js is an event-based server-side JavaScript engine.
Bug#854902: ITP: appimagekit -- package desktop applications as AppImages that run on common Linux-based distributions
Package: wnpp Severity: wishlist Owner: Ritesh Raj Sarraf * Package name: appimagekit Version : git Upstream Author : Simon Peter * URL : https://github.com/probonopd/AppImageKit/ * License : MIT/X Programming Lang: C Description : package desktop applications as AppImages that run on common Linux-based distributions Using AppImageKit you can package desktop applications as AppImages that run on common Linux-based operating systems, such as RHEL, CentOS, Ubuntu, Fedora, Debian and derivatives. The AppImage format is a format for packaging applications in a way that allows them to run on a variety of different target systems (base operating systems, distributions) without further modification. https://en.wikipedia.org/wiki/AppImage AppImageKit is a concrete implementation of the AppImage format and provides tools such as appimagetool and appimaged for conveniently handling AppImages. appimagetool uses a next-generation AppImage format based on squashfs and embeds a runtime for it. appimaged is a daemon that handles registering and unregistering AppImages with the system (e.g., menu entries, icons, MIME types, binary delta updates, and such). Flatpak and Snaps solve similar problems. AppImageKit is comparatively a very simplistic approach. This will be maintained under collab-maint
Bug#854901: ITP: squashfuse -- FUSE filesystem to mount squashfs archives
Package: wnpp Severity: wishlist Owner: Ritesh Raj Sarraf * Package name: squashfuse Version : 0.1 Upstream Author : Dave Vasilevsky * URL : https://github.com/vasi/squashfuse/ * License : BSD Programming Lang: C Description : FUSE filesystem to mount squashfs archives Squashfuse lets you mount SquashFS archives in user-space. It supports almost all features of the SquashFS format, yet is still fast and memory-efficient. So that everyone can use it, squashfuse supports many different operating systems and is available under a permissing license. This package is a depenedency for AppImage, which relies of squashfs for its image format. This package will be maintained under collab-maint
Bug#854891: ITP: case -- Python unittest Utilities
Package: wnpp Severity: wishlist Owner: Christopher Hoskin * Package name: case Version : 1.5.2 Upstream Author : Ask Solem & contributors * URL : https://github.com/celery/case * License : BSD-3-Clause Programming Lang: Python Description : Python unittest Utilities Python unittest Utilities. Includes: . * case.case * case.skip * case.mock * case.utils This is a test dependancy of Vine, which is in turn a dependancy of Celery 4. I intend to maintain it inside the Python Modules Team
Bug#854882: ITP: golang-github-nebulouslabs-bolt -- pure Go key/value store
Package: wnpp Owner: Free Ekanayaka Severity: wishlist * Package name: golang-github-nebulouslabs-bolt Version : 1.2.1 Upstream Author : Ben Johnson * URL or Web page : https://github.com/NebulousLabs/bolt * License : Expat Description : pure Go key/value store Bolt is a pure Go key/value store inspired by Howard Chu's LMDB project. The goal of the project is to provide a simple, fast, and reliable database for projects that don't require a full database server such as Postgres or MySQL. This package is a vendored fork and snapshot of github.com/boltdb/bolt, maintained by NebulousLabs and will be used as a dependency for packaging the sia storage daemon (see ITP #847706). See https://github.com/NebulousLabs/Sia/issues/1565 for why upstream recommends to stick to a vendored version of bolt.
Re: lircd daemon as regular user => device access problems
On 11/02/17 10:29, Bastien Roucaries wrote: Le 10 février 2017 16:13:15 GMT+01:00, Alec Leamas a écrit : Dear list, [cut] Proposed /dev/ permissions after installing lirc: - The /dev/lirc? devices are set user:group lirc:lirc and mode 660 (udev rule). - The lirc user is added to the input group, to access /dev/input devices. - The lirc user is added to the dialout group to access /dev/ttyS devices. - The /var/lock dir is root:root 755 in my stretch box but this is seemingly #813703; assuming this will be fixed to 1777. - lirc user gets read access to all USB character devices using a udev rule invoking facl(1). I know that getting permission is harder than to be forgiven, but perhaps it makes sense to have a discussion first? The possibly controversial issue is the USB devices. However, without this rule a large part of lirc users will be forced to painful udev rules configuration Can we list USB device needed (whitelist) ? I don't think so. The number of devices used by lircd is large, and the USB ids are not always well-defined... It might be possible to whitelist "most" devices, leaving it up to users of "uncommon" devices to fix it on their own. More work for both package maintainers and users, although more safe... Personally I don't think read access to character devices should be that sensitive. The most obvious concern are hardware login dongles. Of those, most seems to be mass storage devices; these are *not* covered by the udev rule. Neither is yubikey devices. Also, whatever risks there are we are already taking them when running lircd as root. --alec
Re: Code in Description [Was: Re: node-tty-browserify_0.0.0-1_amd64.changes REJECTED]
Pirate Praveen writes ("Re: Code in Description [Was: Re:
node-tty-browserify_0.0.0-1_amd64.changes REJECTED]"):
> These packages were rejected and their description is given below.
I agree with ftpmaster's decision in all of these cases.
In the case of node-is-obj and node-is-generator-fn the example
suggested is really too long. In the case of node-pretty-bytes the
my complaint (and ftpmaster's, I think) is that the example should not
be in the first line (what they call the `synopsis').
Sorry,
Ian.
Re: lircd daemon as regular user => device access problems
Le 10 février 2017 16:13:15 GMT+01:00, Alec Leamas a écrit : >Dear list, > >After some work it seems that an updated LIRC package has landed in >stretch without any major problems. This resolves the urgent need to >update it to something recent enough to be supported by upstream. > >One remaining problem is that lircd, the main LIRC daemon, runs as >root. >This is code from the 90's, heavily user-configured. Running this as >root is just not sane, and other distros has moved to running it as a >regular user since long. I want to make this change for sid/buster. > >However, running lircd as non-root raises permissions problems related >to /dev/... devices. Since lircd is configured in all sorts of ways, >many kinds of devices are potentially used. The paranoid configuration >is to block all devices for lircd, leaving it to user to enable them as > >required. This is a breaking update for almost all users. > >The alternative is to use the Fedora strategy, outlined below. This >means changing overall permissions for several /dev/... devices. Is >this >OK, should it be discussed on this ML, or somewhere else? > >Proposed /dev/ permissions after installing lirc: > >- The /dev/lirc? devices are set user:group lirc:lirc and mode 660 >(udev rule). >- The lirc user is added to the input group, to access /dev/input >devices. >- The lirc user is added to the dialout group to access /dev/ttyS >devices. >- The /var/lock dir is root:root 755 in my stretch box but this is >seemingly #813703; assuming this will be fixed to 1777. >- lirc user gets read access to all USB character devices using a udev >rule invoking facl(1). > >I know that getting permission is harder than to be forgiven, but >perhaps it makes sense to have a discussion first? > >The possibly controversial issue is the USB devices. However, without >this rule a large part of lirc users will be forced to painful udev >rules configuration Can we list USB device needed (whitelist) ? Bastien > >Thoughts? > >--alec -- Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.
