Bug#885165: ITP: node-cidr-regex -- Regular expression for matching IP addresses in CIDR notation

[Hemant Yadav]

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

* Package name: node-cidr-regex
  Version : 1.0.6
  Upstream Author : Felipe Apostol  (http://flipjs.io/)
* URL : https://github.com/flipjs/cidr-regex#readme
* License : Expat
  Programming Lang: JavaScript
  Description : Regular expression for matching IP addresses in CIDR
notation

 Regular expression for matching IP addresses in CIDR notation
 .
 Regular expression for matching IP addresses in CIDR notation
 .
 “Regular expression for matching CIDR (Classless Inter-Domain Routing)”.
 .
 Its a simple program for Regular expression for matching IP addresses in
CIDR notation
 .
 Node.js is an event-based server-side JavaScript engine.

This package is a dependency for NPM
.
I would like to maintain this package as part of javascript packaging team.
Praveen has offered to sponser this package.

Bug#885169: ITP: node-npm-bundled -- Parses info on bundled dependencies

[Suman]

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

* Package name: node-npm-bundled
  Version : 1.0.3
  Upstream Author : Isaac Z. Schlueter  (http://blog.izs.me/)
* URL : https://github.com/npm/npm-bundled#readme
* License : ISC
  Programming Lang: JavaScript
  Description : Parses info on bundled dependencies
Npm-bundled gives info regarding bundled dependencies  or transitive
dependencies of bundled dependencies.
.
Node.js is an event-based server-side JavaScript engine.

Praveen agreed to sponser this package.

Re: build 2 similar binary packages from one source tree

[Ryan Kavanagh]

Hi Osamu,

On Mon, Dec 25, 2017 at 01:43:13AM +0900, Osamu Aoki wrote:
> Any pointer to a simple example which uses autotools as its build script
> is appreciated.

The rxvt-unicode source package generates three binary packages, each containing
a version of rxvt-unicode built with different configure flags. The debian/rules
file still does most things manually, but it might be a useful starting point.

Hope this helps,
Ryan

-- 
|_)|_/  Ryan Kavanagh  | GPG: 4E46 9519 ED67 7734 268F
| \| \  https://ryanak.ca/ |  BD95 8F7B F8FC 4A11 C97A


signature.asc
Description: PGP signature

Re: build 2 similar binary packages from one source tree

[Russ Allbery]

Osamu Aoki  writes:

> maildrop source tree can be build with different build option to produce
> maildrop program in 2 ways for each arch.

>  * set GID mail without restricted caller (maildrop)
>  * set UID root with restricted caller for courier-mta
>(maildrop-courier) -- This is now missing in archive but we used to
>have it.

> Of course we can build 2 source packages to do this.  But is there any
> easy clean way to do this without making 2 source packages with
> identical upstream tarball.

> Any pointer to a simple example which uses autotools as its build script
> is appreciated.  (Program example simpler than glibc or linux kernel is
> appreciated.)

libpam-krb5 does this to build an MIT and a Heimdal version of the module,
using dh with upstream autotools.

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

Re: salsa.debian.org (git.debian.org replacement) going into beta

[Holger Levsen]

Hi,

first of all: thanks a lot for all your work on this!

On Mon, Dec 25, 2017 at 11:45:37AM +0100, Alexander Wirt wrote:
> External users are invited to create an account on salsa.

do you plan importing the current -guest accounts from alioth?


-- 
cheers,
Holger


signature.asc
Description: PGP signature

Re: salsa.debian.org (git.debian.org replacement) going into beta

[Alexander Wirt]

On Mon, 25 Dec 2017, Holger Levsen wrote:

Hi, 

> first of all: thanks a lot for all your work on this!
> 
> On Mon, Dec 25, 2017 at 11:45:37AM +0100, Alexander Wirt wrote:
> > External users are invited to create an account on salsa.
> 
> do you plan importing the current -guest accounts from alioth?
No. 

Alex



signature.asc
Description: PGP signature

Bug#885176: ITP: teensy-loader-cli -- load and run programs onto your Teensy micro controller

[Michael Stapelberg]

Package: wnpp
Severity: wishlist
Owner: Michael Stapelberg 

* Package name: teensy-loader-cli
  Version : 2.1
  Upstream Author : Paul Stoffregen  
* URL : https://www.pjrc.com/teensy/loader_cli.html
* License : GPL-3
  Programming Lang: C
  Description : load and run programs onto your Teensy micro controller

See https://www.pjrc.com/teensy/ for an introduction to the Teensy family of
USB-based microcontroller development systems.
.
The teensy loader cli is a command-line alternative to the graphical teensy
loader which is included with Teensyduino. The cli version is preferred by
advanced users who want to automate programming, typically from within a
Makefile or similar.

Re: salsa.debian.org (git.debian.org replacement) going into beta

[Marco d'Itri]

On Dec 25, Alexander Wirt  wrote:

> Every user can create projects in their own namespace (similar to GitHub).
What about git repository URLs?
I am not looking forward to update all Vcs-Git and Vcs-Browser headers 
currently referencing anonscm.debian.org.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#885220: ITP: debian-dad -- Automated Debian package updater

[Balint Reczey]

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

* Package name: debian-dad
  Version : 1
  Upstream Author : Balint Reczey
* URL : https://anonscm.debian.org/cgit/collab-maint/debian-dad.git
* License : AGPL-3.0+
  Description : Automated Debian package updater

Debian's Automated Developer (Dad) is a program preparing updates
for Debian packages automating repetitive tasks of human Developers.
The automated tasks include:

* updating packages to new upstream versions refreshing patches
* updating symbols files using Debian buildd logs

--
The plan is covering way more automated tasks, please refer to the TODO for 
details.
I also plan creating a team for maintenance and patches are always welcome!

Re: Bug#601455: Steps towards a patch to document disabling a daemon upon installation

[Russ Allbery]

Ian Jackson  writes:
> Sean Whitton writes:

>> 2. Do we need to include any text saying *why* the /etc/default practice
>>is a bad idea?  I couldn't come up with a succinct way to state it.
>>In general, I think we can err on the side of not including the text,
>>since we have policy bugs that document the reasons.

> How about this text:

>   Setting a value in /etc/default/PACKAGE is nowadays troublesome
>   because supporting that pattern is very hard due to inflexibility in
>   systemd, which is usually the default init system.

> This also makes it clear that this pattern is perfectly fine if for
> any reason the package does not support systemd.

I don't really agree with this -- I've disliked this approach (and there
were debian-devel threads against it) from long before systemd was
written.  The explanation I'd give is that:

Setting a flag in /etc/default/PACKAGE hides from the init system
whether or not the daemon should actually be started, which leads to
inconsistent and confusing behavior: ``service  start`` may
return success but not start the service, services with a dependency
on this service will be started even though the service isn't running,
and init system status commands may incorrectly claim that the service
was started.

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

Re: Why do we list individual copyright holders?

[Vincent Bernat]

 ❦ 24 décembre 2017 13:24 GMT, Chris Lamb  :

>> Unrelated, but I am developing some kind of "lintian fatigue". […]
>> Sometimes Lintian is right, sometimes it's not.
>
> As you imply, static analysis tools need to maintain a healthy signal-
> to-noise ratio for them to remain relevant and useful.
>
> Needless to say, if Lintian is generating false positives for you,
> please file bugs rather than ignoring all of its output! At the very
> least, If one is seeing a problem, it is likely others are too.

I already often open or reply to bugs in lintian (including when I think
severity is wrong). The main problem is not when lintian is wrong, the
main problem if when lintian is right but is nit-picking. While I
understand some of us would like to reach perfection, it is tiresome to
fix every small issue, notably when they don't have any other effect
than making a tool happy (and a few people) happy. And I never run
lintian at pedantic level.

I think we may loose contributors by trying to be perfect.

As an example, the spelling errors are useful for debian/ directory (as
informational), but totally useless for upstream stuff. For me, they are
not worth telling upstream, they are not worth adding to an override
(which could become outdated and give you another lintian warning).

I have just updated a team-maintained package and I get:

W: python-pyasn1: spelling-error-in-description-synopsis Python Python 
(duplicate word) Python
W: python3-pyasn1: spelling-error-in-description-synopsis Python Python 
(duplicate word) Python

Description: ASN.1 library for Python (Python 2 module)
Description: ASN.1 library for Python (Python 3 module)

Is that a bug? Dunno. I suppose someone with good intentions added that
and now, I have either to open a bug report for lintian, add an
override, fix the duplication or just ignore that hoping it will
eventually go away. I see a discussion already happened about that:
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=822504
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844166

Being perfect was a fine goal when we had 10k packages. We have too many
of them now and we _have_ to maintain them because there are many
dependencies to package for a single package of interest.

We could afford to be perfect again in the future when we will accept
anybody can fix those kind of problems without bothering the
maintainer. People thinking this is important to fix those kind of
problems can just do it themselves.

Currently, the situation is that a few people can push their "agenda"
(replace by a weaker word) to many people by pushing more stuff into
Lintian (or in discussions in d-project or d-devel to "improve"
packaging). And I know that you are open to both sides (I was able to
make you revert a change, don't remember exactly which).
-- 
The smallest worm will turn being trodden on.
-- William Shakespeare, "Henry VI"


signature.asc
Description: PGP signature

Re: salsa.debian.org (git.debian.org replacement) going into beta

[Alexander Wirt]

On Mon, 25 Dec 2017, Marco d'Itri wrote:

> On Dec 25, Alexander Wirt  wrote:
> 
> > Every user can create projects in their own namespace (similar to GitHub).
> What about git repository URLs?
> I am not looking forward to update all Vcs-Git and Vcs-Browser headers 
> currently referencing anonscm.debian.org.
Unfortunately that is something that has to be done. At least unless someone
wants to write some kind of redirection map. 

Alex


signature.asc
Description: PGP signature