Bug#759108: ITP: node-validator -- String validation and sanitization for Node.js

[Tim Retout]

Package: wnpp
Severity: wishlist
Owner: Tim Retout 

* Package name: node-validator
  Version : 3.17.0
  Upstream Author : Chris O'Hara 
* URL : http://github.com/chriso/validator.js
* License : Expat
  Programming Lang: JavaScript
  Description : String validation and sanitization for Node.js

 This library provides various string validation utilities for Node.js.  For
 example, check whether a given string is a valid email or URL, or valid
 JSON.  There are also routines to sanitize strings, e.g. trim whitespace or
 convert to different types.
 .
 Node.js is an event-based server-side JavaScript engine.



This package is a dependency of pump.io.

I will maintain it as part of the Javascript packaging team.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140824112353.7113.98093.reportbug@thinkpad

No feedback on dcut?

[Andreas Metzler]

Hello,

is it normal to not get any kind of feedback on dcut? I was expecting
a confirmation by mail somehow.

The reason I am asking is that I seem to be unable to reschedule
successfully. I want to further delay the *prelude* uploads so they do
not get caught up and further delay the perl transition. It is not
totally broken for me, I succeeded yesterday in rescheduling an upload
to 0-day.

cu Andreas

-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/qk2pcb-n1n@argenau.downhill.at.eu.org

Re: No feedback on dcut?

[Andreas Metzler]

Andreas Metzler  wrote:
[...]
> The reason I am asking is that I seem to be unable to reschedule
> successfully. I want to further delay the *prelude* uploads so they do
> not get caught up and further delay the perl transition.
[..]

Second try, with identical commandline has worked now.

cu Andreas

-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/id4pcb-enf@argenau.downhill.at.eu.org

Re: Standardizing the layout of git packaging repositories

[Mike Gabriel]

Hi Raphael, hi all,

On  Fr 15 Aug 2014 16:16:01 CEST, Raphael Hertzog wrote:


- how do we tag the package releases?

  - pkg/
  (note: git-buildpackage uses debian/ but I find this confusing
  as we then also have the "debian/" prefix for ubuntu or kali uploads, we
  don't need the vendor prefix as the usual versioning rules embed the
  downstream distribution name (e.g. 1.0-0ubuntu1) and thus there can't be
  any conflict on the namespace, keeping a prefix is important to easily
  differentiate tags created by upstream developers from tags created
  by packagers)



As others said before... This will break many many already existing  
Git packaging repositories.


As Debian is the mother distro of all derivatives, debian/  
should be dealt with as synonymous to pkg/. Any other vendor  
can then tag with / and won't conflict with our tags.  
Furthermore, if a tag is debian/, then downstream knows that  
nothing got modified in the downstream derivative distro compared to  
the package in Debian.



- shall we standardize the "pristine-tar" branch?


I'd say "No" here. With packaging of the MATE desktop environment I  
started maintaining only the debian/ folders in the packaging Git  
repositories (e.g. [1]). So, I am not shipping any upstream sources  
with the packaging Git at all. I have started getting fond of this Git  
packaging way and I recommend this to everyone else for various  
reasons (saving storage on git.debian.org for one of them).


Greets,
Mike

[1] http://anonscm.debian.org/cgit/pkg-mate/mate-desktop.git/tree/
--

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
fon: +49 (1520) 1976 148

GnuPG Key ID 0x25771B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb


pgplWisUsGxR6.pgp
Description: Digitale PGP-Signatur

Re: No feedback on dcut?

[Andreas Metzler]

Andreas Metzler  wrote:
> is it normal to not get any kind of feedback on dcut? I was expecting
> a confirmation by mail somehow.

For the archive: 

No it is not normal, it simply happens if you let dcut send out mail
with invalid sender.


Thanks to Ansgar for enlightening me.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/gufpcb-imj@argenau.downhill.at.eu.org

Bug#759131: ITP: libjavaee7-api-java -- JavaEE 7.0 Full API

[Miguel Landaeta]

Package: wnpp
Severity: wishlist
Owner: Miguel Landaeta 

* Package name: libjavaee7-api-java
  Version : 7.0
  Upstream Author : Oracle
* URL : http://docs.oracle.com/javaee/7/api/
* License : GPLv2, CDDL
  Programming Lang: Java
  Description : JavaEE 7.0 Full API

 Java Platform, Enterprise Edition or Java EE is Oracle's enterprise
 Java computing platform. The platform provides an API and runtime
 environment for developing and running enterprise software, including
 network and web services, and other large-scale, multi-tiered,
 scalable, reliable, and secure network applications. Java EE extends
 the Java Platform, Standard Edition (Java SE), providing an API for
 object-relational mapping, distributed and multi-tier architectures,
 and web services.

-- 
Miguel Landaeta, nomadium at debian.org
secure email with PGP 0x6E608B637D8967E9 available at http://miguel.cc/key.
"Faith means not wanting to know what is true." -- Nietzsche


signature.asc
Description: Digital signature

internationalized domain name (IDN) in Debian

[Noël Köthe]

Hello,

I'm collecting the status of IDN in Debian on
https://wiki.debian.org/IDN 

Summary: webbrowser support it in general but email clients still lack
the support of it.

If you could test your not listed client(s) with an IDN domain would
help.

Thank you.


-- 
Noël Köthe 
Debian GNU/Linux, www.debian.org


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

Re: internationalized domain name (IDN) in Debian

[Ralf Jung]

Hey Noël,

> I'm collecting the status of IDN in Debian on
> https://wiki.debian.org/IDN 

Nice :D

> Summary: webbrowser support it in general but email clients still lack
> the support of it.

Why do you list Icedove as non-supporting? I just sent a mail to your
echo service, and got a reply. Is there anything else I should check?

Kind regards
Ralf



signature.asc
Description: OpenPGP digital signature

Re: Reverting to GNOME for jessie's default desktop

[Steve McIntyre]

Joss wrote:
>
>I think there are several ways to do that: 
>  * tweak the debian-cd scripts to build GNOME images for Linux
>architectures and Xfce or MATE images for !linux (I can’t tell
>how hard it is) 

It's perfectly feasible; at the moment, the debian-cd scripts on
pettersson [1,2] pull out information from the tasksel packages to
determine the default desktop etc., but that's not too difficult to
change if we agree to do it.

>  * make stripped-down gnome-core/gnome metapackages for !linux,
>relying on lightdm and gnome-flashback (that I can do) 

Possibly...

>  * hackishly make gnome-core/gnome metapackages depend directly on
>Xfce or MATE for !linux instead of GNOME (same)

Ewww, no!

[1] 
http://anonscm.debian.org/cgit/debian-cd/setup.git/tree/jessie/cronjob.weekly
[2] 
http://anonscm.debian.org/cgit/debian-cd/debian-cd.git/tree/tools/update_tasks

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
You raise the blade, you make the change... You re-arrange me 'til I'm sane...


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1xlcdo-0001sg...@mail.einval.com

Re: internationalized domain name (IDN) in Debian

[Noël Köthe]

Hello Ralf,

Am Sonntag, den 24.08.2014, 20:32 +0200 schrieb Ralf Jung:

> > https://wiki.debian.org/IDN 

> > Summary: webbrowser support it in general but email clients still lack
> > the support of it.
> 
> Why do you list Icedove as non-supporting? I just sent a mail to your
> echo service, and got a reply. Is there anything else I should check?

No, this was a mistake. Just sending/recieving is my first test. This
could be much more extended (from address with IDN, setup wizard with
your email account with IDN domain, IDN certificates,...) but first it
helps to know the software can send IDN emails.

Thanks for your test.


-- 
Noël Köthe 
Debian GNU/Linux, www.debian.org


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

Re: bits from the DPL -- mid-April to mid-August 2014

[Martin Zobel-Helas]

Hi, 

On Sun Aug 24, 2014 at 09:28:11 -0700, Lucas Nussbaum wrote:
> Assets - infrastructure
> ===
> 
> Other minor expenses: SSL certificates (207€ + 180€), cage nuts (10€),
> network switch (417.50€), fans (£43.68), USB cables (£11.39), serial
> terminal adapter (39.08€), serial console adapters (18.04€), rail kit
> (117.84€), extended warranty for a storage array (CAD 784.62)
> 

JFTR: SSL certificates were 180€ only. The 207€ one was what i wrote in
my primary email to leader@, but it was cheaper in the end.

Cheers,
Martin
-- 
 Martin Zobel-Helas Debian System Administrator
 Debian & GNU/Linux Developer   Debian Listmaster
 http://about.me/zobel   Debian Webmaster
 GPG Fingerprint:  6B18 5642 8E41 EC89 3D5D  BDBB 53B1 AC6D B11B 627B 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140824191313.gv2...@ftbfs.de

Bug#759150: ITP: asterisk-testsuite -- test suite for the Asterisk PBX

[Tzafrir Cohen]

Package: wnpp
Severity: wishlist
Owner: Tzafrir Cohen 

* Package name: asterisk-testsuite
  Version : SVN snapshot
  Upstream Author : Matthew Jordan  and various others
* URL : 
https://wiki.asterisk.org/wiki/display/AST/Asterisk+Test+Suite+Documentation
* License : GPL V2 (Same exceptions as Asterisk)
  Programming Lang: Mostly python. Some shell and traces of Lua/C.
  Description : test suite for the Asterisk PBX

 The test suite for the Asterisk PBX software package. Developed as
 a separate package by its developers.

The package includes the test suite of the package asterisk. It is
distributed separately and used for all the development branches.
It is packaged in the pkg-voip git repository:
http://anonscm.debian.org/cgit/pkg-voip/asterisk-testsuite.git/

A small helper binary, asttest, is included in a separate binary
package.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140824202400.15620.67315.report...@pungenday.in.cohens.org.il

Re: Standardizing the layout of git packaging repositories

[Charles Plessy]

Le Sun, Aug 24, 2014 at 02:11:16PM +, Mike Gabriel a écrit :
> 
> >- shall we standardize the "pristine-tar" branch?
> 
> I'd say "No" here. With packaging of the MATE desktop environment I
> started maintaining only the debian/ folders in the packaging Git
> repositories (e.g. [1]). So, I am not shipping any upstream sources
> with the packaging Git at all. I have started getting fond of this
> Git packaging way and I recommend this to everyone else for various
> reasons (saving storage on git.debian.org for one of them).

Hi Mike and everybody,

I have the impression that there is a fundamental misconception in this thread.
“Standardisation” does not mean forcing others to do things that they disagree
with, it means that people who do the same thing talk together and voluntarily
remove some differences between workflows, because they think that it is in
everybody's best interest.

In the case of pristine-tar, the standardisation can be as trivial as “when
using the pristine-tar tool, the branch that contains the deltas should be
called pristine-tar, with no vendor prefix”.

So if you do not use pristine-tar, you do not need to oppose the
standardisation of the use of pristine-tar, because it will not affect you.

Have a nice day,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140824214152.ga12...@falafel.plessy.net

Bug#759168: ITP: libjavamail-api-java -- JavaMail API provides Java classes that model a mail system

[Miguel Landaeta]

Package: wnpp
Severity: wishlist
Owner: Miguel Landaeta 

* Package name: libjavamail-api-java
  Version : 1.5.2
  Upstream Author : Oracle
* URL : https://javamail.java.net/nonav/docs/api/
* License : GPLv2, CDDL
  Programming Lang: Java
  Description : JavaMail API provides Java classes that model a mail system

 The JavaMail API provides a set of abstract classes defining objects
 that comprise a mail system. The API defines classes like Message,
 Store and Transport. The API can be extended and can be subclassed to
 provide new protocols and to add functionality when necessary. 
 .
 In addition, the API provides concrete subclasses of the abstract
 classes. These subclasses, including MimeMessage and MimeBodyPart,
 implement widely used Internet mail protocols and conform to
 specifications RFC822 and RFC2045. They are ready to be used in
 application development. 
 .
 The JavaMail API is designed to serve several audiences: 
 .
  * Client, server, or middleware developers interested in building mail
and messaging applications using the Java programming language.
  * Application developers who need to “mail-enable” their applications. 
  * Service Providers who need to implement specific access and transfer
protocols. 

-- 
Miguel Landaeta, nomadium at debian.org
secure email with PGP 0x6E608B637D8967E9 available at http://miguel.cc/key.
"Faith means not wanting to know what is true." -- Nietzsche


signature.asc
Description: Digital signature

Re: Standardizing the layout of git packaging repositories

[Brian May]

On 24 August 2014 04:24, Russ Allbery  wrote:

> Right, exactly.  That's super-annoying to do if you were keeping
> everything mixed together in the master branch, much easier if you were
> keeping separate branches for each fix but keeping those separate branches
> is itself incredibly annoying, and utterly trivial if you're using gbp pq
> or git-dpm.  The latter take a little bit of getting used to, and are then
> almost as fast as just making changes directly in Git, but let you
> actually send isolated fixes upstream.
>

I would find it annoying to keep around lots of branches in the hope that
one day upstream might integrate them. (One reason I also like Gerrit)

I like to minimize the number of branches I have, so I can easily keep
track of what I am actually working on.

More then likely, in X years time when upstream looks at it, the branch
will be gone.

Not relevant if you have a very responsive upstream


I would never use quilt directly.  Been there, done that, have no interest
> in doing it again.  I like Git.  But using it as an export format for
> patch-queue branches works really well.


What do you use instead? quilt is the only tool I know who to use here, and
it is starting to irritate me - I keep making changes and forgetting to add
the files to the patch first, and screwing everything up. What tool(s)
should I learn to solve this?
-- 
Brian May 

Bug#759170: ITP: r-cran-e1071 -- GNU R package with miscellaneous functions of the Dept of Statisics (e1071)

[Dirk Eddelbuettel]

Package: wnpp
Owner: Dirk Eddelbuettel 
Severity: wishlist

* Package name: r-cran-e1071
  Version : 1.6-3-1
  Upstream Author : David Meyer, Evgenia Dimitriadou, Kurt Hornik, Andreas 
Weingessel, and Friedrich Leisch.
* URL or Web page : http://cran.rstudio.com/web/packages/e1071/index.html
* License : GPL-2
  Description : GNU R package with miscellaneous functions of the Dept of 
Statisics (e1071)

This package is a Build-Depends: of RcmdrMisc (== r-cran-rcmdrmisc) which
itself is a Build-Depends of Rcmdr (== r-cran-cmdr) which is a package we had
in Debian for a decade.

e1071 is a stable package which reflects work by the authors when working in
the Dept of Statistics at TU Wien.  They have all moved on to different
departments/universities, and the package is in maintenance mode.

It includes a wrapper to libsvm which itself is BSD licensed and pretty
widely used within R via this package.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/8761hhe8jj@max.nulle.part

Bug#759176: ITP: golang-qml.v0 -- Graphical QML application support for the Go language

[Sergio Schvezov]

Package: wnpp
Severity: wishlist
Owner: Sergio Schvezov 

* Package name: golang-qml.v0
  Version : 0.0~git20140824-1
  Upstream Author : Gustavo Niemeyer 
* URL : http://gopkg.in/qml.v0
* License : LGPL
  Programming Lang: Go
  Description : Graphical QML application support for the Go language

Package qml offers graphical QML application support for the Go
language.

This package allows to easily add a UI to applications written with Go.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140825014304.14802.46425.reportbug@rivendell

Re: Standardizing the layout of git packaging repositories

[Russ Allbery]

Brian May  writes:
> On 24 August 2014 04:24, Russ Allbery  wrote:

>> Right, exactly.  That's super-annoying to do if you were keeping
>> everything mixed together in the master branch, much easier if you were
>> keeping separate branches for each fix but keeping those separate
>> branches is itself incredibly annoying, and utterly trivial if you're
>> using gbp pq or git-dpm.  The latter take a little bit of getting used
>> to, and are then almost as fast as just making changes directly in Git,
>> but let you actually send isolated fixes upstream.

> I would find it annoying to keep around lots of branches in the hope
> that one day upstream might integrate them. (One reason I also like
> Gerrit)

> I like to minimize the number of branches I have, so I can easily keep
> track of what I am actually working on.

> More then likely, in X years time when upstream looks at it, the branch
> will be gone.

Yeah, exactly.  That's the thing that ended up annoying me about the
feature branch approach.  gbp pq handles that in a fairly nice way and
lets you not have to deal with multiple branches, and git-dpm I believe
does as well (although I've not personally used it).

> What do you use instead? quilt is the only tool I know who to use here,
> and it is starting to irritate me - I keep making changes and forgetting
> to add the files to the patch first, and screwing everything up. What
> tool(s) should I learn to solve this?

git-buildpackage's gbp pq system is what I use.  I believe git-dpm is more
complicated and comprehensive, but gbp pq is simple enough in its
operations that it doesn't take long to wrap your mind around it.

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87d2bpw8da@hope.eyrie.org

Re: Standardizing the layout of git packaging repositories

[Barry Warsaw]

On Aug 24, 2014, at 08:33 PM, Russ Allbery wrote:

>git-buildpackage's gbp pq system is what I use.  I believe git-dpm is more
>complicated and comprehensive, but gbp pq is simple enough in its
>operations that it doesn't take long to wrap your mind around it.

git-dpm seems pretty easy to use as well.  YMMV, but ultimately I think both
helpers achieve the same goals.  Over in debian-python@ we're having some good
discussions related to moving the Debian Python team over to git, and many
folks have contributed useful stories and experiences.

I'm beginning to think that what we want is for gbp and git-dpm to
interoperate, such that any individual maintainer can use whichever tool they
choose, but would still allow the team to adhere to consensus recommendations,
so there's no guesswork involved.  E.g. the ultimate artifacts would end up
being the same, regardless of whether you used gbp, git-dpm, or plain vanilla
git + quilt.  One example of a superficial differences is the tag names used
by default.  They're different between the two helpers, but really needn't be.

-Barry


signature.asc
Description: PGP signature

Re: Standardizing the layout of git packaging repositories

[Brian May]

On 25 August 2014 14:34, Barry Warsaw  wrote:

> I'm beginning to think that what we want is for gbp and git-dpm to
> interoperate, such that any individual maintainer can use whichever tool
> they
> choose, but would still allow the team to adhere to consensus
> recommendations,
> so there's no guesswork involved.  E.g. the ultimate artifacts would end up
> being the same, regardless of whether you used gbp, git-dpm, or plain
> vanilla
> git + quilt.  One example of a superficial differences is the tag names
> used
> by default.  They're different between the two helpers, but really needn't
> be.
>

Unless I am mistaken, I think both  gbp pq and git-dpm store different data
in git, so cannot interoperate on the same tree.

i.e. by the looks of it, gbp pq only bothers to keep the most recent set of
patches in git, and stores the history of old patches  old versions of
debian/patches/.

Where as git-dpm uses git for the authoritative source for past patches,
and also keeps track of stuff in debian/.git-dpm.

Am still learning how this stuff works, but so far I don't think
interoperation is possible. It looks like decision needs to be made on a
per tree basis.
-- 
Brian May