Bug#656957: ITP: gppcscconnectionplugin -- PC/SC connection plugin for GlobalPlatform Library

[Dmitry Eremin-Solenikov]

Package: wnpp
Severity: wishlist
Owner: "Dmitry Eremin-Solenikov" 

* Package name: gppcscconnectionplugin
  Version : 1.1.0
  Upstream Author : Karsten Ohme 
* URL : http://globalplatform.sourceforge.net/
* License : LGPL-v3
  Programming Lang: C
  Description : PC/SC connection plugin for GlobalPlatform Library

 This package provides a GlobalPlatform library a possibility
 to use PC/SC middleware/daemon to access smart cards.



-- 
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/20120123083328.1574.11143.report...@valinor.lumag.spb.ru

Bug#656959: ITP: gpshell -- GlobalPlatform smart card script interpreter

[Dmitry Eremin-Solenikov]

Package: wnpp
Severity: wishlist
Owner: "Dmitry Eremin-Solenikov" 

* Package name: gpshell
  Version : 1.4.4
  Upstream Author : Karsten Ohme 
* URL : http://globalplatform.sourceforge.net
* License : GPL-v3
  Programming Lang: C
  Description : GlobalPlatform smart card script interpreter

 GPShell is a script interpreter which talks to a smart card.  It is written
 on top of the GlobalPlatform library, which was developed by Karsten Ohme.
 It uses smart card communication protocols ISO-7816-4 and OpenPlatform 2.0.1
 and GlobalPlatform 2.1.1. It can establish a secure channel with a smart card,
 load, instantiate, delete, list applets on a smart card.



-- 
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/20120123090733.1974.15211.report...@valinor.lumag.spb.ru

Bug#657019: Please document why the package includes non-PIC code

[Reinhard Tartler]

Package: x264
Version: 2:0.116.2042+git178455c-1
Severity: wishlist

Bug forwarded from https://bugs.launchpad.net/bugs/919509

Seems that according to Policy §10.2, we need to document why we are not
building the shared library with -fPIC in the file README.Debian and get
consensus on that on the debian-devel mailing list.

The reason is that x264 uses a lot of hand written assembler, and
upstream takes care to use non-pic code only on architectures that
support this.

Btw, the same applies to the libav* packages.

Cheers,
Reinhard



-- 
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/20120123135322.14419.36245.report...@faui43f.informatik.uni-erlangen.de

Re: cross-build-essential

[Wookey]

+++ Paul Wise [2012-01-21 20:37 +0800]:
> On Thu, Jan 19, 2012 at 8:10 PM, Wookey wrote:
> 
> > Currently on Debian you'll need to have made the emdebian repositories
> > available because otherwise you won't find any cross-compilers, but
> > hopefully we'll have them in the main archive in the not-too distant.
> 
> Whats the status/blockers for getting these into Debian main?

To do this properly requires cross-dependencies to be enabled/allowed
in the buildd and archive infrastructure. arm-linux-gnueabi-gcc
build-depends on libc-dev:armel

Currently the buildd's don't know how to do this, and we don't allow
either build-depenencies or package dependecnies outside the
architecture.

After discussions at last year's debconf everyone is basically happy
that this stuff should be allowed where a good case is made (and this
is a good case), but various bits of infrastructure and scripts need
to be tweaked so they still work.

Currently debian cross-tools are built by the emdebian team (well,
Hector Oron in practice) using the buidlcross script (in experimental
these days) which uses dpkg-cross to generate the cross-libraries and
do the builds. 

Ubuntu uses a different scheme, with a package that depends on the
various linux-source, binutils-source, gcc-source, eglibc-source
packages to do a 3-stage bootstrap and thus generate cross-packages.
This avoids cross-arch dependencies so it can be built in existing
infrastructure. Unfortunately the maintainer has never quite managed
to get his jobs list short enough to upload this to Debian, and it's
always going to be an interim solution anyway. 

Last feb when we mooted uploading this for the time being it made
sense. Having got to this point I'd prefer to fix the cross-arch
dependency issues and upload some cleaner cross-compiler packages.

However right now no-one is really working on this much. Hector is
busy with armhf stuff (and a new job). I'm working on sbuild/buildd
multiarch cross-building. 

If anyone wants to take the glory by actually making this work (it
probably isn't very hard at this stage) you are very welcome. The
debian-embedded list is the place where this stuff gets discussed.

> I would dearly like to be able to compile ARM stuff elsewhere than on
> my phone since it is a bit slow ;)

Would be nice wouldn't it? You should be able to use the emdebian
cross-tools fairly painlessly, but they do regularly get out-of-sync
with the main archive due to 'busy maintainers' syndrome which then
causes breakage. 

Wookey
-- 
Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.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/20120123152844.gx10...@dream.aleph1.co.uk

Re: collab-maint join requests on Alioth

[Holger Levsen]

On Montag, 23. Januar 2012, Enrico Zini wrote:
> in order to make collab-maint[1] applications on Alioth faster, we would
> like to introduce a super light procedure. Here it is:

very cool, thanks!


-- 
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/201201231836.43176.hol...@layer-acht.org

Bug#657044: ITP: libcpan-perl-releases-perl -- module for mapping Perl releases on CPAN to the location of the tarballs

[gregor herrmann]

Package: wnpp
Owner: gregor herrmann 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org

* Package name: libcpan-perl-releases-perl
  Version : 0.42
  Upstream Author : Chris Williams 
* URL : http://search.cpan.org/dist/CPAN-Perl-Releases/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : module for mapping Perl releases on CPAN to the location of 
the tarballs

CPAN::Perl::Releases is a module that contains the mappings of all Perl
releases that have been uploaded to CPAN to the authors/id/ path that the
tarballs reside in.

This is static data, but newer versions of this module will be made available
as new releases of Perl are uploaded to CPAN.



-- 
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/20120123181302.ga19...@belanna.comodo.priv.at

Re: Bug#657019: Please document why the package includes non-PIC code

[Russ Allbery]

Reinhard Tartler  writes:

> Bug forwarded from https://bugs.launchpad.net/bugs/919509

> Seems that according to Policy §10.2, we need to document why we are not
> building the shared library with -fPIC in the file README.Debian and get
> consensus on that on the debian-devel mailing list.

> The reason is that x264 uses a lot of hand written assembler, and
> upstream takes care to use non-pic code only on architectures that
> support this.

> Btw, the same applies to the libav* packages.

Sounds good to me.  This is exactly the sort of package that can sometimes
benefit from this and is pretty much in the center of the reason for that
exception.

-- 
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: http://lists.debian.org/87vco2i8me@windlord.stanford.edu

Bug#657067: ITP: futures -- backport of concurrent.futures package from Python 3.2

[Sandro Tosi]

Package: wnpp
Severity: wishlist
Owner: Sandro Tosi 

* Package name: futures
  Version : 2.1.2
  Upstream Author : Alex Grönholm 
* URL : http://pypi.python.org/pypi/futures
* License : BSD
  Programming Lang: Python
  Description : backport of concurrent.futures package from Python 3.2

 The concurrent.futures module provides a high-level interface for
 asynchronously executing callables.
 .
 This is a backport for concurrent.futures as of PEP-3148 and included in
 Python 3.2



-- 
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/20120123202403.682.86498.report...@oracle.matrix.int

Re: Bug#657067: ITP: futures -- backport of concurrent.futures package from Python 3.2

[Russ Allbery]

Sandro Tosi  writes:

> * Package name: futures
>   Version : 2.1.2
>   Upstream Author : Alex Grönholm 
> * URL : http://pypi.python.org/pypi/futures
> * License : BSD
>   Programming Lang: Python
>   Description : backport of concurrent.futures package from Python 3.2

>  The concurrent.futures module provides a high-level interface for
>  asynchronously executing callables.
>  .
>  This is a backport for concurrent.futures as of PEP-3148 and included in
>  Python 3.2

python-futures for the package name, surely, no?

-- 
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: http://lists.debian.org/87aa5egmd8@windlord.stanford.edu

Re: Bug#657067: ITP: futures -- backport of concurrent.futures package from Python 3.2

[Sandro Tosi]

On Mon, Jan 23, 2012 at 22:06, Russ Allbery  wrote:
> python-futures for the package name, surely, no?

do you mean the binary? that will be python-concurrent.futures, as per
python policy; for the source I'm open to comments

Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi


-- 
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/capdtaj2yfzknblfruo5lqwjsd4sw3vp+k1hxgusblaa42h+...@mail.gmail.com

Re: Bug#657067: ITP: futures -- backport of concurrent.futures package from Python 3.2

[Russ Allbery]

Sandro Tosi  writes:
> On Mon, Jan 23, 2012 at 22:06, Russ Allbery  wrote:

>> python-futures for the package name, surely, no?

> do you mean the binary? that will be python-concurrent.futures, as per
> python policy; for the source I'm open to comments

I was thinking of the source.  If you're building a single binary package
from the source package, it's usually better for everyone's level of
confusion to just name the source package the same as the binary package.
But my main point was just to avoid having a source package named
"futures"; that's a little general.  :)

-- 
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: http://lists.debian.org/87r4yqf6nu@windlord.stanford.edu

Re: Bug#657067: ITP: futures -- backport of concurrent.futures package from Python 3.2

[Jakub Wilk]

* Russ Allbery , 2012-01-23, 13:30:

python-futures for the package name, surely, no?
do you mean the binary? that will be python-concurrent.futures, as per 
python policy; for the source I'm open to comments
I was thinking of the source.  If you're building a single binary 
package from the source package, it's usually better for everyone's 
level of confusion to just name the source package the same as the 
binary package. But my main point was just to avoid having a source 
package named "futures"; that's a little general.  :)


I normally advocate using upstream name for source package name (even if 
it's a single binary package and the binary package would have a 
different name due to $LANGUAGE policy). However, in this case I agree 
that "futures" would be too generic.


--
Jakub Wilk


--
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/20120123214454.ga7...@jwilk.net

mentors.debian.org as the pseudopackage (Re: proposed new pseudo-package 'debian-mentors' for handling sponsoring requests)

[Don Armstrong]

On Tue, 17 Jan 2012, Ansgar Burchardt wrote:
> SUMMARY
> ===
> 
> We plan to ask for the creation of a new pseudo-package
> debian-mentors or mentors.debian.org [3] (contact:
> debian-ment...@lists.debian.org) in Debian's bug tracking system (the
> name is still subject to change). A workflow for handling sponsoring
> requests is proposed below. It is based on an earlier discussion on the
> debian-mentors list[1].
> 
> The workflow will also be made available on [2].
> 
> [1] 
> 
> [2] 

I believe that mentors.debian.org is a better name for the
pseudopackage. In a brief query with DSA, they are in principle ok
with having mentors.debian.org point to www.debian.org/devel/mentors
(or some similar subpage in the w.d.o hierarchy) explaining the
mentoring process and the workflow for the mentors.debian.org
pseudopackage.

From my owner@bdo perspective, I am willing to create the
pseudopackage mentors.debian.org in the BTS assuming that:

1) www.debian.org/devel/mentors (or similar) has been created

2) The requirements for a psuedopackage in
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=544192#10 coupled
with a bug report against bugs.debian.org asking for the creation of
the psuedopackage.

3) DSA gives a final OK on creating the mentors.debian.org name with a
redirect to that subpage.


Don Armstrong

-- 
You think to yourself, hey, it's a test tube, for God's sake. Pretty
soon, though, the rush from a test tube isn't enough. You want to
experiment more and more. Then before you know it, you're laying in
the corner of a lab somewhere with a Soxhlet apparatus in one hand,
a three neck flask in the other, strung out and begging for grant
money.
 -- Tim Mitchell, 1994 Ig Nobel Chemistry Prize Speech

http://www.donarmstrong.com  http://rzlab.ucr.edu


--
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/20120123220119.gc21...@rzlab.ucr.edu

Bug#657082: ITP: flufl.password -- password hashing and verification for Python

[Barry Warsaw]

Package: wnpp
Severity: wishlist
Owner: Barry Warsaw 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: flufl.password
  Version : 1.1.1
  Upstream Author : Barry Warsaw 
* URL : http://launchpad.net/flufl.password
* License : LGPL
  Programming Lang: Python
  Description : password hashing and verification for Python

This package provides some utilities for hashing and verifying
passwords, as well as generating user-friendly passwords.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBCAAGBQJPHdlYAAoJEBJutWOnSwa/Z7kP/3zv4g8r5Nwndp2ky7oRNNfQ
ezf+DAQx8SPmlZ1FbabU23KIJDd42y958I4KZBuTGHVyWwkV5C+XqHwcAppDC4Ja
NPW7Kzz0bwK3wL6ufQ3TuCsQdXQvajt6FEnoUK+VJAcnkw0TyVigjw3qWZPaYTTq
MU7Jute3hsanD2yyf0amlehkaNdubGeZyE7WzOjS/LeioNdMnDS1aHZLnhxGBHy9
Ef5qkDqGmtLXigQPe3YyoZIXqLBGTUgaWPGiBrTUlTv3dCk8G2TB5pYbhdbwv7Df
uv9B0q+LjR8hgcnUB4BeuycUq7MhlqIMpf4cvMmt6NrjrJJLuvmnMR/SGvApzC1F
GObPkALjGfBs09XoBWmq7IqpG3pfrkOWju23twAkx3wQonbZWkPwfHUv7/x8tXLT
ZkaZtbQp9nF36Mq3itypLvdoWxg1k/1AWI0ZkoLwA4Upnt7s42blVSLyi9zwfvV0
MYq0BUu4cRm4lZWE96gI3+TBaNkH04HV4UE347C9aDy+Ec9pC18S8C0541itADIr
+UJD0G6xym4PWiiO66+o2SndHROwd8C3YaQH9XlkQjvMJUblxqdvpu2/z4afT6hK
lHG+xYz2eXP4gd+plb6U08TKFOW61U1D6OJBbNgRPY/OKDu0Gk7CxY8eQvBzJHZA
La2XhCtCZ0L4UjAPaUfD
=W/I9
-END PGP SIGNATURE-



-- 
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/20120123220411.2677.55588.report...@chemistry.wooz.org

Re: Bug#657067: ITP: futures -- backport of concurrent.futures package from Python 3.2

[Russ Allbery]

Jakub Wilk  writes:

> I normally advocate using upstream name for source package name (even if
> it's a single binary package and the binary package would have a
> different name due to $LANGUAGE policy).

This can make things unnecessarily awkward and confusing for, say, the
BTS.  Nothing that people can't deal with, but in the Perl group we had a
discussion about this a while back and decided to always stick with
calling the source package and the binary package the same thing if the
source only builds one binary.

-- 
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: http://lists.debian.org/87ehuqf4nx@windlord.stanford.edu

Re: Bug#657067: ITP: futures -- backport of concurrent.futures package from Python 3.2

[Don Armstrong]

On Mon, 23 Jan 2012, Jakub Wilk wrote:
> I normally advocate using upstream name for source package name
> (even if it's a single binary package and the binary package would
> have a different name due to $LANGUAGE policy).

If you are only building one binary package, the source package should
have the same name. The exception to this guideline is when the binary
package name is expected to change over the lifetime of the source
package. [For example, if the binary name contains a soname.]

Otherwise you can end up with confusing cases where a package with
source foo builds binary bar, and binary foo is built by source bar.

The language guidelines for binary packages exist to avoid cluttering
the package namespace, and they should generally be applied to source
packages too.


Don Armstrong

-- 
2: There is no out. There is only in.
  -- "The Prisoner (2009 Miniseries)"

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
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/20120123221619.gd21...@rzlab.ucr.edu

Re: proposed new pseudo-package 'debian-mentors' for handling sponsoring requests

[Octavio Alvarez]

On Tue, 17 Jan 2012 13:59:14 -0800, Ansgar Burchardt 
wrote:


We propose to use the BTS to handle sponsoring requests. Both sponsorees
and sponsors should already be familiar with its usage and we hope it
will improve the sponsoring process for both sides. It will also make it
easier to analyse sponsoring (e.g. number of requests without a
response).


As a non-developer, I really like this idea.

Just a note, though: the non-automatic subscription behavior of the
BTS could confuse new potential package maintainers, as they might
not subscribe to the corresponding bug (this has happened to me).

This should be noted in the documentation.

In other issue tracking systems, the requester is automatically
notified of any response or follow-up in the reported case.

Best regards.

--
Octavio.


--
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/op.v8j7kpqp4oyyg1@alvarezp-ws

Please add a sponsorship-requests pseudo-package

[Arno Töll]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Package: bugs.debian.org
Severity: wishlist

Hello,

as we seem to have reached general consensus about the approach to
handle sponsor requests in the BTS. The last thing subject to discussion
is the name of the pseudo-package to agree upon.

Zack made a good suggestion to me, which I proposed to people interested
in this discussion, and we all seemed to agree that
"sponsorship-requests" is a good name for the pseudo-package, letting
alone the mentors.debian.net -> .org discussion entirely.

For the record: The related thread started in [1] and in a IRC
discussion with don we (ansgar, gregoa, jwilk, bremner, paultag, myself)
seemed to agree to this name proposal.

Hence, please add a "sponsorship-requests" pseudo-package with
debian-ment...@lists.debian.org as a package owner and we can get started.


[1] http://lists.debian.org/debian-mentors/2012/01/msg00365.html
- -- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJPHfpSAAoJEMcrUe6dgPNtrDsQAKC5l9gcrJOWs+XYm22B7Qu/
OUByldrHbz6A2pWL31RKHVqNG2ybwlqTQK+BuSZ42Ybh5hTXuLSilZzv6x3Upayu
2GDd1ChvTmVdS1AluaHSpSbrEKkOfRREljmfsLmJVpmGAM9HDFJ6NoXnFzXdsXdf
aoWhVh0jnMCvCI+MTcyMzDxGosHT56yPM4WmS/jHsnleg45gW6HbF12ZQOAok8uB
LnGmsDVmPqO5ssorMDv4zWxCZe57l5STRmrVr5UYNqCh1gFT9Du9AcYLAqPgkBqF
XAZoEJqYLovoKdXqnXfXYEfnZj4SFAVBt37/FQDR58wpIGgSvhRKbTRpPdKODuVr
2Q1U6CRYyRTMRRNouT06UFFgbo5jfDr88g1d4MFjQFxGlnpvDysVR4q4XQ1eTvL2
GleZ1xGHtcs2hiDtDYWHVjLyS80iSQU4OxfRGFGMciTaQ6OtoIN+e1sXr3YyqKNn
rjf4X8fXeYROlOCya0u+uRBPKYx5fuRbCKu4plGggBEL1VgP1xMpjquKv2l3StxF
V3oaNASaY8T36InQSnGwVaQ5GTfz4XmvQypqL4yAHqYX1EzbNCFsA9cV2meJYN6Z
oXVs1WyFZzSpFkudupF8T0oqJdx9uGl3HhRfx4/FpZzNq5k+PM4CTcDlvVBB83QL
5okOydvNxpKGL4srdQyq
=UqNj
-END PGP SIGNATURE-


-- 
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/4f1dfa52.1030...@toell.net

Re: collab-maint join requests on Alioth

[Raphael Hertzog]

Hi,

On Mon, 23 Jan 2012, Enrico Zini wrote:
>  * What happens next?
> 
> A few days after all the steps have been completed, you should get an
> email from Alioth saying that you are now a member of the collab-maint
> project.

I don't know if this has been fixed on the FusionForge side, but when I
was processing collab-maint, this was not the case. Alioth did not send
out such mails (i.e. when you accepted/declined a join request).

If that's still the case, you might want to ask the sponsor to CC his
mail to the person requesting access so that you can group reply and
inform that the request has been processed.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/liberation/


-- 
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/20120124065710.gf7...@rivendell.home.ouaza.com

Bug#657114: ITP: barnyard2 -- output processor for Snort

[Andrew Pollock]

Package: wnpp
Severity: wishlist
Owner: Andrew Pollock 

* Package name: barnyard2
  Version : 1.9
  Upstream Author : Ian Firns >
* URL : http://www.securixlive.com/barnyard2/
* License : GPLv2
  Programming Lang: C,
  Description : output co-processor for Snort

Barnyard2 is a fork of the original barnyard project, designed specifically for
Snort's new unified2 file format.

Barnyard is a critical tool for the parsing of Snort's unified binary files,
processing and on-forwarding to a variety of output plugins. 

It:

+ Offloads output processing of your Snort alert files to a dedicated process,
  minimising dropped packets in Snort itself.
+ Parses unified2 files.
+ Uses similar configuration syntax to that of Snort to simplify deployment.
+ Supports all Snort output plugins (except alert_sf_socket) as well as two
  additional plugins (Sguil and CEF).



-- 
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/20120124065035.4479.62511.report...@icarus.andrew.net.au