Re: [PATCH] netplug - Allow to specify custom script file via param '-s'

[Pali Rohár]

On Saturday 23 March 2013 09:48:27 Raphael Hertzog wrote:
> On Sat, 23 Mar 2013, Philipp Matthias Hahn wrote:
> > > When I am in a similar situation, I tend to offer the
> > > person to join as co-maintainer. The patch is not very
> > > long and it should not be too hard to review. Or you can
> > > redirect him towards upstream if that's better.
> > 
> > Upstream is dead: 
> > 2010-06-26 So basically I would need to maintain that patch
> > ad infinitum. And currently I don't have the time to become
> > a new upstream, so my rather harsh reply.
> 
> That's something that Pali deserved to know. He wrote a patch
> and he uses it, he could be the next upstream maintainer...
> who knows?
> 
> I do the same mistake from time to time, but just because
> someone is on the other side of the bug report, doesn't mean
> that he should be considered only as a mere user.
> 
> Cheers,

So is my patch totally ignored? I sent it to upstream maintainer, 
next to debian mailinglist, attached to debian bug tracking 
system, sent to ubuntu mailinglist and also to launchpad ubuntu 
bug tracker. And nobody reviewed it until now... So where should 
be patches sent for review and for inclusion to system?

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH] netplug - Allow to specify custom script file via param '-s'

[Andrew Shadura]

Hello,

On Wed, 27 Mar 2013 12:08:20 +0100
Pali Rohár  wrote:

> So is my patch totally ignored? I sent it to upstream maintainer, 
> next to debian mailinglist, attached to debian bug tracking 
> system, sent to ubuntu mailinglist and also to launchpad ubuntu 
> bug tracker. And nobody reviewed it until now... So where should 
> be patches sent for review and for inclusion to system?

I contacted upstream few days ago on IRC; it seems he's rather busy
now. I think you need to wait for a while :)

-- 
WBR, Andrew


signature.asc
Description: PGP signature

Bug#704054: /etc/environment.d

[adrelanos]

Package: general
Severity: wishlist

I'd like to have a /etc/environment.d folder. Contributing that code
shouldn't be hard for me. But I don't know where the would be the best
place to implement it and how?

http://codesearch.debian.net tells, that many packages read
/etc/environment directly, not using some system mechanism to get the
contents of it, which makes the implementation harder.

Asking all affected packages to read /etc/environment.d as well or to
start using a system function to do that seems unlikely?

The most realistic option could be to write something similar to
resolvconf, i.e. creating a package which phrases /etc/environment.d
and dynamically creates /etc/environment.

Please tell me what you think.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5152ec11.1020...@riseup.net

Bug#704054: /etc/environment.d

[Josselin Mouette]

Le mercredi 27 mars 2013 à 12:54 +, adrelanos a écrit : 
> Package: general
> Severity: wishlist
> 
> I'd like to have a /etc/environment.d folder. Contributing that code
> shouldn't be hard for me. But I don't know where the would be the best
> place to implement it and how?

Please don’t encourage maintainers to make packages depend on a given
environment. It is generally a bug to have such a requirement, therefore
such a framework is not needed.

-- 
 .''`.  Josselin Mouette
: :' :
`. `'
  `-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1364389772.3634.381.camel@pi0307572

Bug#704059: ITP: sdb -- simple and fast key/value database

[Peter Pentchev]

Package: wnpp
Severity: wishlist
Owner: Peter Pentchev 

* Package name: sdb
  Version : 0.6
  Upstream Author : pancake 
* URL : http://github.com/radare/sdb
* License : public domain
  Programming Lang: C
  Description : simple and fast key/value database

  sdb is a simple key/value database with disk storage, based on cdb, but
  with various optimizations and improvements related to both the on-disk
  format and the runtime processing.  Its core API supports querying and
  modifying data within JSON objects stored in the database, as well as
  references to external sdb databases using namespaces.

I am aware that a slightly outdated version of the sdb sources is
distributed within the radare2 source package, but I have the feeling
that this library also merits distribution on its own.

G'luck,
Peter

-- 
Peter Pentchev  r...@ringlet.net r...@freebsd.org p.penc...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13
If this sentence were in Chinese, it would say something else.


signature.asc
Description: Digital signature

Bug#704076: ITP: node-archy -- Pretty-print nested hierarchies module for Node.js

[Jérémy Lal]

Package: wnpp
Severity: wishlist
Owner: "Jérémy Lal" 

* Package name: node-archy
  Version : 0.0.2
  Upstream Author : James Halliday 
* URL : https://github.com/substack/node-archy
* License : Expat
  Programming Lang: JavaScript
  Description : Pretty-print nested hierarchies module for Node.js

Given a tree of nested objects with 'label' and 'nodes' fields,
node-archy returns a string representation of that tree with unicode
pipe characters.
.
Node.js is an event-based server-side javascript engine.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130327165438.15280.26205.reportbug@imac.chaumes

Bug#704054: /etc/environment.d

[Steve Langasek]

On Wed, Mar 27, 2013 at 12:54:41PM +, adrelanos wrote:
> Package: general
> Severity: wishlist

> I'd like to have a /etc/environment.d folder. Contributing that code
> shouldn't be hard for me. But I don't know where the would be the best
> place to implement it and how?

As Joss says, packages should not rely on /etc/environment's contents;
there should be no need to manage this as anything other than a simple file
under the control of the user.

> http://codesearch.debian.net tells, that many packages read
> /etc/environment directly, not using some system mechanism to get the
> contents of it, which makes the implementation harder.

The /etc/environment file is owned by pam.  Other packages are not meant to
be reading it directly, because contrary to appearances it is NOT defined as
a shell snippet, but as a shell-like config file parsed by pam_env
internally.  Packages *are* allowed to assume /etc/default/locale is
shell-parseable and parse it directly, as this is a file defined expressly
for sharing locale information between all relevant consumers (including pam
services, and display managers which need to know the locale to use /before/
authenticating the user).

And I would not accept a patch like this to the pam package.  pam's code is
very security-sensitive, which makes this a high-risk, low-benefit change. 
It should be done upstream if at all, but I don't think upstream will go for
it either.

> Asking all affected packages to read /etc/environment.d as well or to
> start using a system function to do that seems unlikely?

> The most realistic option could be to write something similar to
> resolvconf, i.e. creating a package which phrases /etc/environment.d
> and dynamically creates /etc/environment.

That would at least not require changes to pam_env, but having to generate
files in /etc from other files is ugly and should be avoided unless
absolutely necessary.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130327173644.gb26...@virgil.dodds.net

Bug#704054: /etc/environment.d

[Lars Wirzenius]

On Wed, Mar 27, 2013 at 10:36:44AM -0700, Steve Langasek wrote:
> On Wed, Mar 27, 2013 at 12:54:41PM +, adrelanos wrote:
> > Package: general
> > Severity: wishlist
> 
> > I'd like to have a /etc/environment.d folder. Contributing that code
> > shouldn't be hard for me. But I don't know where the would be the best
> > place to implement it and how?

Now that the specific technical change has been opposed: adrelanos, could
you describe the actual problem you wanted to solve with /etc/environment.d?
Perhaps there is a better solution we can suggest for that.

-- 
http://www.cafepress.com/trunktees -- geeky funny T-shirts
http://gtdfh.branchable.com/ -- GTD for hackers


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130327174539.gb4...@mavolio.codethink.co.uk

Bug#704098: ITP: node-retry -- Retry strategies for failed operations module for Node.js

[Jérémy Lal]

Package: wnpp
Severity: wishlist
Owner: "Jérémy Lal" 

* Package name: node-retry
  Version : 0.0.6
  Upstream Author : Tim Koschützki 
* URL : https://github.com/tim-kos/node-retry
* License : Expat
  Programming Lang: JavaScript
  Description : Retry strategies for failed operations module for Node.js

node-retry abstracts exponential and custom retry strategies for failed
perations. Its parameters are the number of retries, exponential
factor, minimum and maximum (randomized) timeouts.
.
Node.js is an event-based server-side javascript engine.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130327212452.10089.46233.reportbug@imac.chaumes

Bug#704100: ITP: jubatus -- jubatus: Distributed Online Machine Learning Framework

[John Paul Adrian Glaubitz]

Package: wnpp
Severity: wishlist
Owner: John Paul Adrian Glaubitz 

* Package name: jubatus
  Version : 0.4.2
  Upstream Author : The Jubatus Team 
* URL : http://jubat.us
* License : LGPL v2.1
  Programming Lang: C++, Python
  Description : jubatus: Distributed Online Machine Learning Framework

Jubatus is a distributed online machine learning framework developed by
Japan's Nippon Telegraph & Telephone (NTT) and Preferred Infrastructure
Corporation (PFI).

It can be used to analyse data in real time allowing to assist making forecasts
for markets, detecting frauds, predicting natural disasters, estimating parts
and material procurement for manufacturing, making assesments about health
risks and providing predictive techniques in life and natural sciences.

Jubatus is provided as a library and provides client libraries with bindings
for C++, Python, Ruby and Java. An online tutorial and extensive documentation
are provided both in English and Japanese on the Jubatus homepage. Support
can be obtained through Google Groups, news updates are posted on Twitter
(@JubatusOfficial) as well as the Jubatus blog.

Note:

I have already been in touch with upstream and notified them that I would like
to package Jubatus for Debian. Since Jubatus is still a rather young project
and thus subject to frequent API changes and code clean ups, the Jubatus team
asked me to allow them to get the code a bit more into shape before they
consider it ready for offical packaging. I have filed this ITP already to
express my interest to become the maintainer of Jubatus in Debian nevertheless.

People who want to try out Jubatus in the mean time can resort to the Debian
and RPM packages provided by the Jubatus team themselves.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130327220127.6867.16735.reportbug@localhost.localdomain

Bug#704103: ITP: node-read -- Read user input from stdin module for Node.js

[Jérémy Lal]

Package: wnpp
Severity: wishlist
Owner: "Jérémy Lal" 

* Package name: node-read
  Version : 1.0.4
  Upstream Author : Isaac Z. Schlueter 
* URL : https://github.com/isaacs/read
* License : BSD-2-clause
  Programming Lang: JavaScript
  Description : Read user input from stdin module for Node.js

node-read extends Node.js readline.question builtin method with options
like silent input, replaced input, timeout or default value.
.
Node.js is an event-based server-side javascript engine.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130327222311.17798.76616.reportbug@imac.chaumes

Bug#704104: ITP: node-mute-stream -- Pass-through stream that can be muted module for Node.js

[Jérémy Lal]

Package: wnpp
Severity: wishlist
Owner: "Jérémy Lal" 

* Package name: node-mute-stream
  Version : 0.0.3
  Upstream Author : Isaac Z. Schlueter 
* URL : https://github.com/isaacs/mute-stream
* License : BSD-2-clause
  Programming Lang: JavaScript
  Description : Pass-through stream that can be muted module for Node.js

node-mute-stream is a basic pass-through stream, but when muted,
the bytes are silently dropped, rather than being passed through.
.
Node.js is an event-based server-side javascript engine.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130327223723.20307.68423.reportbug@imac.chaumes

Excelencia Administrativa para Secretarias y Asistentes

[Estas a Tiempo Todavia]

Estimado usuario, construya relaciones fuertes y prepárese desde hoy para los 
retos más grandes que enfrentará en su carrera.

Seminario de Excelencia Administrativa para Secretarias, Asistentes y Personal 
de Oficina.
Horario: De 9:00 a.m. a 2:00 p.m. y de 4:00 p.m. a 9:00 p.m.
Fecha: 11 de Abril   /  Sede: México, D.F.
Fecha: 17 de Abril   /  Sede: Monterrey, N.L.
Fecha: 19 de Abril   /  Sede: Guadalajara, Jal.

Asista y conozca las herramientas, estrategias y técnicas esenciales para 
prosperar en el ambiente de negocios de hoy y crecer en su carrera 
administrativa. Nuestras sesiones le proporcionarán información de las nuevas 
tendencias de trabajo para los profesionales administrativos.

Nuestro programa le ayudará a hacer más eficientes los procesos, negociar con 
proveedores para aumentar la productividad.

Descubra:
- Nuevos enfoques para manejar la tecnología.
- Ser proactiva: Dos y tres pasos adelante de su Jefe.
- Habilidades de organización para priorizar actividades cruciales.
- Sentirse auto-motivada (en términos de desarrollo y crecimiento profesional 
progresivo).

¡Obtenga la Información Completa sin compromiso!

Reciba un folleto completo de este programa, solo responda este correo con los 
siguientes datos y se lo enviaremos a la brevedad.
Nombre:
Teléfono:
Empresa:
Sede de Interés:

O bien, comuníquese con nosotros a nuestro Centro de Atención Telefónica al 
01800-212.06.60

Será un placer atenderle
Lic. Ericka Camacho
Líder de Proyectos

Reenvíe esta invitación a compañeros que les pueda ser de utilidad.
Para darte de baja debian-devel@lists.debian.org y no recibir ningún tema de 
nuestra empresa, envíe un correo con asunto FinalizarPromo.



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/067746e6bb0dd40c69e99a2d001b7...@intelligencefinancial.info

Re: Bug#704054: /etc/environment.d

[Thomas Goirand]

On 03/27/2013 08:54 PM, adrelanos wrote:
> Package: general
> Severity: wishlist
>
> I'd like to have a /etc/environment.d folder. Contributing that code
> shouldn't be hard for me. But I don't know where the would be the best
> place to implement it and how?
>
> http://codesearch.debian.net tells, that many packages read
> /etc/environment directly, not using some system mechanism to get the
> contents of it, which makes the implementation harder.
>
> Asking all affected packages to read /etc/environment.d as well or to
> start using a system function to do that seems unlikely?
>
> The most realistic option could be to write something similar to
> resolvconf, i.e. creating a package which phrases /etc/environment.d
> and dynamically creates /etc/environment.
>
> Please tell me what you think.
I might sound silly, but ... what is /etc/environment for? What
are the packages reading it, and for what use?

Thomas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5153dc0c.4060...@debian.org

Re: Bug#704054: /etc/environment.d

[Salvatore Bonaccorso]

Hi Thomas

On Thu, Mar 28, 2013 at 01:58:36PM +0800, Thomas Goirand wrote:
> On 03/27/2013 08:54 PM, adrelanos wrote:
> > Package: general
> > Severity: wishlist
> >
> > I'd like to have a /etc/environment.d folder. Contributing that code
> > shouldn't be hard for me. But I don't know where the would be the best
> > place to implement it and how?
> >
> > http://codesearch.debian.net tells, that many packages read
> > /etc/environment directly, not using some system mechanism to get the
> > contents of it, which makes the implementation harder.
> >
> > Asking all affected packages to read /etc/environment.d as well or to
> > start using a system function to do that seems unlikely?
> >
> > The most realistic option could be to write something similar to
> > resolvconf, i.e. creating a package which phrases /etc/environment.d
> > and dynamically creates /etc/environment.
> >
> > Please tell me what you think.
> I might sound silly, but ... what is /etc/environment for? What
> are the packages reading it, and for what use?

It is the default environment file for the pam_env.so module from
libpam-modules package. It allows (un)setting specific environment
variables. See for example for the su service, in the session
management group:

, [ /etc/pam.d/su ]
| [...]
| # This module parses environment configuration file(s)
| # and also allows you to use an extended config
| # file /etc/security/pam_env.conf.
| #
| # parsing /etc/environment needs "readenv=1"
| session   required   pam_env.so readenv=1
| # locale variables are also kept into /etc/default/locale in etch
| # reading this file *in addition to /etc/environment* does not hurt
| session   required   pam_env.so readenv=1 envfile=/etc/default/locale
| [...]
`

Regards,
Salvatore


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130328062004.ga7...@elende.valinor.li