Re: Bug#753704: ITP: amap -- Next-generation scanning tool for pentesters

[Geoffrey Thomas]

On Mon, 7 Jul 2014, Adam Borowski wrote:


By the way, it would be nice to have a common scheme for installing wrappers
of this kind -- especially if /bin vs /usr/bin is going to go away.


If you're open to dpkg-divert, config-package-dev lets you do this. Taking 
molly-guard as an example, install the wrapper as 
/sbin/shutdown.molly-guard and configure it to exec 
shutdown.molly-guard-orig. Then (assuming dh7-style) write 
"/sbin/shutdown.molly-guard" to debian/molly-guard.displace, and pass 
--with=config-package to dh. config-package-dev will insert appropriate 
maintainer script snippets to divert /sbin/shutdown and place a symlink 
from /sbin/shutdown to shutdown.molly-guard.


config-package-dev is primarily intended for downstream distributions and 
other similar uses outside the Debian archive, but it seems like using it 
this way within the archive would be policy-compliant, and probably more 
in the spirit of policy than taking advantage of the relative positions of 
entries in $PATH.


--
Geoffrey Thomas
https://ldpreload.com
geo...@ldpreload.com


--
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/alpine.deb.2.10.1407061920020.21...@cactuar.ldpreload.com

Re: Bug#753704: ITP: amap -- Next-generation scanning tool for pentesters

[Adam Borowski]

On Mon, Jul 07, 2014 at 12:19:15AM +0200, Jakub Wilk wrote:
> * Adam Borowski , 2014-07-06, 21:04:
> >I see some legitimate scenarios for a single package to have
> >something both in $X/bin and $X/sbin, but not really across
> >package boundaries.
> 
> These are deliberate:

None of your examples break policy 10.1: they don't install something with a
different functionality, just wrappers and/or different implementation.
The abuse we're trying to prevent is putting totally different things under
the same basename, like amap the biology tool vs amap the network scanner.

> * safe-rm ships /usr/bin/rm;
> * molly-guard ships /usr/sbin/{halt,poweroff,reboot,shutdown}

These are wrappers which add some checks.
 
> * elvis-tiny ships /bin/vi (like other vi clones, it also installs
> an alternative for /usr/bin/vi)

This provides a lightweight implementation of same functionality for those
who use the obsolescent /usr split.

Another case would be colorgcc or ccache: they use PATH ordering (not
installed by default) to do their thing.

By the way, it would be nice to have a common scheme for installing wrappers
of this kind -- especially if /bin vs /usr/bin is going to go away.

> Would you call them “legitimate” or not?

I'd use the policy 10.1 test here: variants of same functionality are
legitimate, unrelated functionality is not.

-- 
Gnome 3, Windows 8, Slashdot Beta, now Firefox Ribbon^WAustralis.  WTF is going
on with replacing usable interfaces with tabletized ones?


-- 
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/20140707013113.ga13...@angband.pl

Re: Bug#753704: ITP: amap -- Next-generation scanning tool for pentesters

[Marco d'Itri]

On Jul 07, Jakub Wilk  wrote:

> Would you call them “legitimate” or not?
I would call them "a future problem" since the world is moving to using 
/usr/bin/ for everything and I expect that we will follow as well in 
a couple of releases.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Bug#753962: ITP: ghp-import -- Easily import docs to your gh-pages branch

[Thomas Koch]

On Sunday, July 06, 2014 07:14:49 PM Andrew Starr-Bochicchio wrote:
> Inside your repository just run `ghp-import $DOCS_DIR` where $DOCS_DIR
> is the path to the built documentation. This will write a commit to your
> gh-pages branch with the current documents in it.
> 
> While I'm no fan of license proliferation, the Tumbolia Public License
> seems to meet the requitements of the DFSG.

Having a quick look at the code of ghp-import it seems to me that I can easily 
replace it with a shell two-liner in my projects makefile. I'd much more 
welcome an addition to the packages git-extras or git-stuff which could do:

- prepare a git-tree from a directory with all objects written to the object 
store
- commit this tree to a branch that is not currently checked out
- A combined command of the above two.

Both actions must not touch the index.

Regards, Thomas Koch


-- 
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/201407062351.51848.tho...@koch.ro

Re: Bug#753962: ITP: ghp-import -- Easily import docs to your gh-pages branch

[Andrew Starr-Bochicchio]

On Sun, Jul 6, 2014 at 5:51 PM, Thomas Koch  wrote:
> On Sunday, July 06, 2014 07:14:49 PM Andrew Starr-Bochicchio wrote:
>> Inside your repository just run `ghp-import $DOCS_DIR` where $DOCS_DIR
>> is the path to the built documentation. This will write a commit to your
>> gh-pages branch with the current documents in it.
>>
>> While I'm no fan of license proliferation, the Tumbolia Public License
>> seems to meet the requitements of the DFSG.
>
> Having a quick look at the code of ghp-import it seems to me that I can easily
> replace it with a shell two-liner in my projects makefile. I'd much more
> welcome an addition to the packages git-extras or git-stuff which could do:
>
> - prepare a git-tree from a directory with all objects written to the object
> store
> - commit this tree to a branch that is not currently checked out
> - A combined command of the above two.
>
> Both actions must not touch the index.

My main reason for packaging this is that python-pelican uses it in
the github target of the Makefiles it generates. [0] Maybe I should
mention that in the description. I was planning on using an Enhances
field in debian/control.

[0] http://docs.getpelican.com/en/latest/tips.html#publishing-to-github

Thanks,

-- Andrew Starr-Bochicchio

   Ubuntu Developer 
   Debian Developer 
   PGP/GPG Key ID: D53FDCB1


-- 
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/cal6k_ax-zosb-x7kffikug_b-b8anslaswhnq6wdg_dp1kv...@mail.gmail.com

Re: Bug#753704: ITP: amap -- Next-generation scanning tool for pentesters

[Jakub Wilk]

* Adam Borowski , 2014-07-06, 21:04:
I see some legitimate scenarios for a single package to have something 
both in $X/bin and $X/sbin, but not really across package boundaries.


These are deliberate:

* safe-rm ships /usr/bin/rm;

* molly-guard ships /usr/sbin/{halt,poweroff,reboot,shutdown}

* elvis-tiny ships /bin/vi (like other vi clones, it also installs an 
alternative for /usr/bin/vi)



Would you call them “legitimate” or not?

--
Jakub Wilk


--
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/20140706221915.ga1...@jwilk.net

Bug#753992: ITP: libmarpa -- BNF grammar parser

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: libmarpa
  Version : 6.1.0
  Upstream Author : Jeffrey Kegler
* URL : https://jeffreykegler.github.io/Marpa-web-site/libmarpa.html
* License : LGPL-3+~Marpa
  Programming Lang: C
  Description : BNF grammar parser

 Libmarpa is a C implementation of the core of Marpa parsing algorithm.
 .
  * Marpa parses anything you can write in BNF, including ambiguous and
even infinitely ambiguous grammars.
  * Marpa easily and efficiently handles both left- and right-recursion.
  * If a grammar is in one of the classes in practical use today, Marpa
parses it in O(n) (linear) time.
  * Marpa never goes exponential. Worst case, even for wildly ambiguous
grammars, is O(n3) (cubic) time.
  * Marpa's run-time error detection is revolutionary. Marpa has
complete situational awareness. It knows at all times which rules it
is attempting to apply, how far it has progressed in them, and
exactly which tokens it can accept. And Marpa can communicate its
situational awareness back to the application.
  * Marpa allows the application to efficiently retry rejected input.
This, combined with its situational awareness, allows
"Ruby Slippers" parsing: When an application has a token rejected,
it can ask the parse engine which tokens would be acceptable. It can
then create a virtual token that allows the parse to continue -- the
application can make the parse engine's "wishes" come true. The Ruby
Slippers are easy to use and surprisingly wide in their application.
 .
 Marpa is named after the legendary 11th century Tibetan translator,
 Marpa Lotsawa.

This library is currently part of libmarpa-r2-perl, but will be provided
as a separate shared library in future releases.

 - Jonas

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQF8BAEBCgBmBQJTubbqXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ3NjQ4ODQwMTIyRTJDNTBFQzUxRDQwRTI0
RUMxQjcyMjM3NEY5QkQ2AAoJEE7BtyI3T5vWECIIALoU2x3l3fvHanbhA8QkSH85
pV+QaJXkbqj/qkduvPOxM5CH2NloXq7KrFrPO0W0YpmXEaUXP7T++PlyirO0eoYJ
LvGC34ycRRU5kcH2MiBxqgFQgN0gBo2+Wv3UaxH0YFuaT9OOPwPuxzVvQTKm97Tf
lgUYySTy4yr6Hed7NYqhu4BP8/XlqkAx2FubYpuUkRks8hC5uxeyOBVApyirGtSj
qn7FNxcc3NBRdGZiTl2AOjcsSmVP1ojsy+yEWohZc+7lWGFYQ87Q07intgPPO9BB
GFBO3oMWDrMPuRi0+/QXOF9scGthMJJ1HHsOLJOsOUSX+gG78j4r2+/mTGJtKMU=
=3Xk7
-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: 
https://lists.debian.org/20140706205158.26707.52587.report...@bastian.jones.dk

Re: Bug#753704: ITP: amap -- Next-generation scanning tool for pentesters

[Guillem Jover]

Hi!

On Sun, 2014-07-06 at 21:04:25 +0200, Adam Borowski wrote:
> On Sun, Jul 06, 2014 at 04:02:05PM +0100, Lars Wirzenius wrote:
> > The standards FHS directory layout gives us four locations in which to
> > put executabes: /bin, /sbin, /usr/bin, /usr/sbin. In theory we could
> > then have four providers of yoyo, but that would be very confusing.
> > Even using bin vs sbin is confusing: if you're used to running foo's
> > yoyo as your normal user, it'll be quite a surprise when you try to
> > run it as root and get bar's yoyo instead.
> 
> Thus, what about adding this to the Policy?  These five locations (also
> /usr/games) should be considered the same wrt file conflicts.
> 
> I see some legitimate scenarios for a single package to have something both
> in $X/bin and $X/sbin, but not really across package boundaries.

  

Thanks,
Guillem


-- 
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/20140706195636.ga...@gaara.hadrons.org

Re: Bug#753704: ITP: amap -- Next-generation scanning tool for pentesters

[Adam Borowski]

On Sun, Jul 06, 2014 at 04:02:05PM +0100, Lars Wirzenius wrote:
> The standards FHS directory layout gives us four locations in which to
> put executabes: /bin, /sbin, /usr/bin, /usr/sbin. In theory we could
> then have four providers of yoyo, but that would be very confusing.
> Even using bin vs sbin is confusing: if you're used to running foo's
> yoyo as your normal user, it'll be quite a surprise when you try to
> run it as root and get bar's yoyo instead.

Thus, what about adding this to the Policy?  These five locations (also
/usr/games) should be considered the same wrt file conflicts.

I see some legitimate scenarios for a single package to have something both
in $X/bin and $X/sbin, but not really across package boundaries.

-- 
Gnome 3, Windows 8, Slashdot Beta, now Firefox Ribbon^WAustralis.  WTF is going
on with replacing usable interfaces with tabletized ones?


-- 
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/20140706190425.ga9...@angband.pl

Re: ITP: schema2ldif -- Tool for converting OpenLDAP-style schemas to the LDIF

[Ryan Tandy]

On 06/07/14 04:03 AM, Bastian Blank wrote:

On Fri, Jul 04, 2014 at 03:58:28PM +0200, Benoit Mortier wrote:

  schema2ldif will read the given input file and convert it to an LDIF file
  that you can insert into you LDAP directory


Did you talk to the openldap maintainers if they would be willing to
ship this small tool?  The script only provides openldap specific
output.


Benoit, if you agree with that, would you consider converting your ITP 
to a wishlist bug against openldap? We can discuss it more there, but I 
agree that such a script would be nice to have in the package.


Compared to using a slapd tool for schema conversion, this script's 
approach has some nice properties, such as preserving comments and 
formatting, and not requiring dependency schema to be provided.



--
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/53b99b3d.1090...@nardis.ca

Re: dpkg-source to automatically add a Testsuite field

[Martin Pitt]

Hey Guillem,

Guillem Jover [2014-07-06 18:35 +0200]:
> Given that dpkg-dev has recognized the Testsuite field for some time,
> I don't really see a reason for dpkg-source not to automatically add
> it to the generated .dsc with an “autopkgtest” value if there is a
> debian/tests/control file around, instead of requiring maintainers
> to remember to set it manually.

Absolutely. In fact this was even discussed back then, that's why
README.package-tests.rst says "Future versions of dpkg-source might
add this automatically when a ``debian/tests/control`` file is
present." I just forgot to file a dpkg wishlist bug for that.

> Reading the spec [S], it seems to me that the file can be empty, as
> it states “This is a file containing zero or more RFC822-style
> stanzas”, so the code cannot do any sanity check, like checking if
> the file contains one stanza with a Tests field. So it will only
> check for the file presence.

That seems fine. A file with zero will cause the result "SKIP no tests
in this package", which should be as expected.


> I've queued a patch doing exactly that for dpkg 1.17.11. If there's
> any known reservations with that, please speak up.

Yay, thanks!

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.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/20140706181100.gb3...@piware.de

Bug#753975: ITP: kallithea -- free software source code management system

[Jelmer Vernooij]

Package: wnpp
Severity: wishlist
Owner: Jelmer Vernooij 

* Package name: kallithea
  Version : 0.0
  Upstream Author : Various authors
* URL : https://www.kallithea-scm.org/
* License : Mostly GPLv3
  Programming Lang: Python, JavaScript
  Description : free software source code management system

Kallithea hosts code, manages access control lists and provides an
easy web interface to Git and Mercurial repositories.

Kallithea is a fork of RhodeCode, see
http://sfconservancy.org/news/2014/jul/04/kallithea-joins/ for
background.

If you're interested in co-maintaining this package, send me an email.


signature.asc
Description: Digital signature

Bug#753962: ITP: ghp-import -- Easily import docs to your gh-pages branch

[Andrew Starr-Bochicchio]

Package: wnpp
Severity: wishlist
Owner: "Andrew Starr-Bochicchio" 

* Package name: ghp-import
  Version : 0.4.1
  Upstream Author : Paul Joseph Davis 
* URL : https://github.com/davisp/ghp-import
* License : Tumbolia Public License
  Programming Lang: Python
  Description : Easily import docs to your gh-pages branch

ghp-import is a Python script meant to make using GitHub's gh-pages
branches for hosting documentation simple.
.
Inside your repository just run `ghp-import $DOCS_DIR` where $DOCS_DIR
is the path to the built documentation. This will write a commit to your
gh-pages branch with the current documents in it.


While I'm no fan of license proliferation, the Tumbolia Public License
seems to meet the requitements of the DFSG.

> Copying and distribution of this file, with or without modification,
> are permitted in any medium without royalty provided the copyright
> notice and this notice are preserved.
>
> TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
>
>  0. opan saurce LOL

Thoughts?

Thanks!

- Andrew Starr-Bochicchio


-- 
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/20140706171449.24962.47936.reportbug@asb-laptop

dpkg-source to automatically add a Testsuite field

[Guillem Jover]

Hi!

Given that dpkg-dev has recognized the Testsuite field for some time,
I don't really see a reason for dpkg-source not to automatically add
it to the generated .dsc with an “autopkgtest” value if there is a
debian/tests/control file around, instead of requiring maintainers
to remember to set it manually.

Reading the spec [S], it seems to me that the file can be empty, as it
states “This is a file containing zero or more RFC822-style stanzas”,
so the code cannot do any sanity check, like checking if the file
contains one stanza with a Tests field. So it will only check for the
file presence.

  [S] 


I've queued a patch doing exactly that for dpkg 1.17.11. If there's
any known reservations with that, please speak up.

Thanks,
Guillem


-- 
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/20140706163547.ga30...@gaara.hadrons.org

Re: Bug#753704: ITP: amap -- Next-generation scanning tool for pentesters

[Lars Wirzenius]

On Sun, Jul 06, 2014 at 10:49:30PM +0900, Charles Plessy wrote:
> Le Sun, Jul 06, 2014 at 10:33:35AM +0200, Andreas Tille a écrit :
> > On Sat, Jul 05, 2014 at 04:37:16PM +0200, Ralf Treinen wrote:
> > > > 
> > > > This violates the Policy's section 10.1, but it is still my
> > > > favorite solution for the reason that you explained above.
> > > 
> > > I don't agree, packages should not be in conflict when it can be
> > > easily avoided by renaming files.
> > 
> > +1
> 
> Hi Andreas,
> 
> Feel free to rename yourself, but do not forget to remove me from
> the uploaders list.
> 
> On my side I find these renamings harmful and illogical. The
> probability that people want to use both amaps on the same machine
> is close to zero, and the probability that users of both amaps will
> be annoyed by the rename is close to one. I think that these
> renamings are applied dogmatically in a way that makes Debian
> inferior. I do not want to participate to this.

I can see, and sympathise, with several sides of this debate of what
to do when two upstream projects choose the same executable name.
However, I do think what Debian's historically been doing (i.e.,
renaming even when upstream doesn't want to rename) is the right thing
to do.

Given projects foo and bar, which both provide an executable called
yoyo, there is no way for everyone to be happy. Both foo's and bar's
users are, presumably, used to calling it yoyo. Third party scripts
will exist that invoke either using the name yoyo. Whichever yoyo
Debian chooses to call by that name, some users will be surprised and
unhappy.

The standards FHS directory layout gives us four locations in which to
put executabes: /bin, /sbin, /usr/bin, /usr/sbin. In theory we could
then have four providers of yoyo, but that would be very confusing.
Even using bin vs sbin is confusing: if you're used to running foo's
yoyo as your normal user, it'll be quite a surprise when you try to
run it as root and get bar's yoyo instead.

We could have the foo and bar packages conflict with each other, and
in some cases that might not be too bad. However, it would be really
unfortunate for long-term quality, in my opinion, if Debian would
start choosing to compromise like that. It may be true that the
intersection of users of foo and bar are really rare, and that nobody
much would suffer if they conflicted, but it sets a bad precedent.
Conflicts in Debian are meant to be used for a specific reason: when
two packages _can't_ be used together (at least not as packaged). If
we use conflicts to resolve the yoyo for foo and bar, it means that we
are willing to change the meaning of conflicts to also be allowed when
we just can't be bothered to make difficult distro level integration
decisions.

Using conflicts doesn't solve the situation for users, anyway. bar's
users will still be surprised by foo's yoyo, when they find it
installed and it doesn't do what they thought it would. Of course,
foo's users are in the same situation, if foo's yoyo gets renamed.

For this reason, I think the best approach is to get at least one of
foo's or bar's upstreams to rename their yoyo. If that can't happen, I
further think it's better for Debian's users if Debian renames at
least one of the yoyo's. Which one gets renamed will depend on
circumstance. The default, historically, has been that the first yoyo
in Debian keeps the name, and newer yoyos will be renamed. However, if
bar is extremly popular, and foo is rarely used, then possibly foo's
yoyo should be renamed. Or we could decide to rename both to avoid
anyone being surprised by the wrong yoyo.

Note that the Debian alternatives system can't be used for this,
unless foo and bar are both basically implementing essentially the
same interface for the same program, but that's rarely the case in
these cases.

Charles, I'm sorry to hear you think this approach is harmful to
Debian and that you don't want to participate in doing them.

-- 
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: https://lists.debian.org/20140706150205.gl30...@exolobe1.liw.fi

Re: Bug#753704: ITP: amap -- Next-generation scanning tool for pentesters

[Gianfranco Costamagna]

> Il Domenica 6 Luglio 2014 15:51, Charles Plessy  ha 
> scritto:
> > Le Sun, Jul 06, 2014 at 10:33:35AM +0200, Andreas Tille a écrit :
> 
>>  On Sat, Jul 05, 2014 at 04:37:16PM +0200, Ralf Treinen wrote:
>>  > > 
>>  > > This violates the Policy's section 10.1, but it is still my 
> favorite solution
>>  > > for the reason that you explained above.
>>  > 
>>  > I don't agree, packages should not be in conflict when it can be 
> easily avoided
>>  > by renaming files.
>> 
>>  +1
> 
> Hi Andreas,
> 
> Feel free to rename yourself, but do not forget to remove me from the 
> uploaders
> list.
> 
> On my side I find these renamings harmful and illogical.  The probability that
> people want to use both amaps on the same machine is close to zero, and the
> probability that users of both amaps will be annoyed by the rename is close to
> one.  I think that these renamings are applied dogmatically in a way that 
> makes
> Debian inferior.  I do not want to participate to this.
> 

Hi Charles,

I really don't think there is any reason to rename your package.
I renamed my amap into amap-thc, and this should be fully 10.1 compliant now.
Since my package is a new one there is no reason to avoid such a rename, and I 
can work with new packages depending on it to patch them in the right way.

The package also creates a link into "amap6", so really *nobody* should *ever* 
use directly amap (for my case).
If they do this, yes, I call it a bug.

So please don't touch your package and I'm uploading a new version of mine with 
all your really nice suggestions ;)

Cheers!

Gianfranco

> Cheers,
> 
> -- 
> 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/1404658137.56179.yahoomail...@web171805.mail.ir2.yahoo.com

Re: Sources licensed under PHP License and not being PHP are not distributable

[Holger Levsen]

Hi,

while going through the list of (new) RC bugs claiming to affect wheezy, I 
noticed a whole bunch of "$foo is licensed under the PHP license and is not 
PHP" ones and am wondering if removal from stable is planned as well.

Is it?


cheers,
Holger


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

Bug#753942: ITP: s3curl -- Calculates the proper signature to interact with S3 HTTP services, then calls cURL with the appropriate arguments

[Sebastien Delafond]

Package: wnpp
Severity: wishlist
Owner: Sebastien Delafond 

* Package name: s3curl
  Version : 1.0
  Upstream Author : Amazon Inc.
* URL : https://aws.amazon.com/developertools/Amazon-S3/128
* License : Apache 2.0
  Programming Lang: Perl
  Description : Easily interact with S3 HTTP services

Calculates the proper signature to interact with S3 HTTP services, then
calls cURL with the appropriate arguments.


-- 
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/20140706140210.29618.78417.report...@hetz1.mine.nu

Re: Bug#753704: ITP: amap -- Next-generation scanning tool for pentesters

[Charles Plessy]

Le Sun, Jul 06, 2014 at 10:33:35AM +0200, Andreas Tille a écrit :
> On Sat, Jul 05, 2014 at 04:37:16PM +0200, Ralf Treinen wrote:
> > > 
> > > This violates the Policy's section 10.1, but it is still my favorite 
> > > solution
> > > for the reason that you explained above.
> > 
> > I don't agree, packages should not be in conflict when it can be easily 
> > avoided
> > by renaming files.
> 
> +1

Hi Andreas,

Feel free to rename yourself, but do not forget to remove me from the uploaders
list.

On my side I find these renamings harmful and illogical.  The probability that
people want to use both amaps on the same machine is close to zero, and the
probability that users of both amaps will be annoyed by the rename is close to
one.  I think that these renamings are applied dogmatically in a way that makes
Debian inferior.  I do not want to participate to this.

Cheers,

-- 
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/20140706134930.ga2...@falafel.plessy.net

Bug#753933: ITP: node-batch -- Simple async batch

[Leo Iannacone]

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

* Package name: node-batch
  Version : 0.5.1
  Upstream Author : TJ Holowaychuk 
* URL : https://github.com/visionmedia/batch
* License : Expat
  Programming Lang: JavaScript
  Description : async batch - Node.js module
 This modules provides an async batch with concurrency control
 and progress reporting.
 .
 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: https://lists.debian.org/53b93a3e.426cc20a.5855.2...@mx.google.com

Bug#753932: ITP: node-serve-index -- Serve directory listings

[Leo Iannacone]

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

* Package name: node-serve-index
  Version : 1.1.4
  Upstream Author : Douglas Christopher Wilson 
* URL : https://github.com/expressjs/serve-index
* License : Expat
  Programming Lang: JavaScript
  Description : Serve directory listings

 FIX_ME bug long description
 .
 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: https://lists.debian.org/53b93a19.a24cc20a.1208.0...@mx.google.com

Re: ITP: schema2ldif -- Tool for converting OpenLDAP-style schemas to the LDIF

[Bastian Blank]

On Fri, Jul 04, 2014 at 03:58:28PM +0200, Benoit Mortier wrote:
>  schema2ldif will read the given input file and convert it to an LDIF file
>  that you can insert into you LDAP directory

Did you talk to the openldap maintainers if they would be willing to
ship this small tool?  The script only provides openldap specific
output.

Bastian

-- 
"Life and death are seldom logical."
"But attaining a desired goal always is."
-- McCoy and Spock, "The Galileo Seven", stardate 2821.7


-- 
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/20140706110338.gc25...@mail.waldi.eu.org

Re: ITP: schema2ldif -- Tool for converting OpenLDAP-style schemas to the LDIF

[Mike Gabriel]

Hi Benoit,

On  Fr 04 Jul 2014 15:58:28 CEST, Benoit Mortier wrote:


Package: wnpp
Severity: wishlist
Owner: Benoit Mortier 

* Package name: schema2ldif
  Version : 0.1
  Upstream Author : Come Bernigaud 
* URL : https://forge.fusiondirectory.org/projects/schema2ldif
* License : GPL
  Programming Lang: Perl
  Description : Tool for converting OpenLDAP-style schemas to the LDIF
format

 schema2ldif will read the given input file and convert it to an LDIF file
 that you can insert into you LDAP directory


ping me if you need a sponsor.

Mike
--

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


pgph10vqSCohg.pgp
Description: Digitale PGP-Signatur

Bug#753928: ITP: naemon -- Host, service and network monitoring and management system

[Mike Gabriel]

Package: wnpp
Severity: wishlist
Owner: Mike Gabriel 

* Package name: naemon
  Version : 0.8.0
  Upstream Author : Naemon Development Team 
* URL : http://www.naemon.org
* License : GPL-2+
  Programming Lang: C
  Description : Host, service and network monitoring and management system

 Naemon is a monitoring and management system for hosts, services and
 networks.
 .
 Naemon features include:
 .
  *  Monitoring of network services (via TCP port, SMTP, POP3, HTTP, NNTP,
 PING, etc.)
  *  Plugin interface to allow for user-developed service checks
  *  Contact notifications when problems occur and get resolved (via email,
 pager, or user-defined method)
  *  Ability to define event handlers to be run during service or host events
 (for proactive problem resolution)
  *  Web output (current status, notifications, problem history, log file, etc.)
 .
 Naemon has been written in C and is designed to be easy to understand and
 modify to fit your own needs.
 .
 Naemon is a NAGIOSv4 fork with focus on project transperancy. It is a project 
 from the community for the community.


-- 
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/20140706102836.23406.54471.report...@minobo.das-netzwerkteam.de

Re: Bug#753704: ITP: amap -- Next-generation scanning tool for pentesters

[costamagnagianfra...@yahoo.it]

Hi Javier,

thanks for your hint!

That was my first thoght, I'm upstream developer and DM of ettercap and we 
already install in sbin some of the binaries.

The problem is:
what does it happen when the user have both amap installed on the system and 
runs "amap" from the bash?

This might be highly confusing for the end user, and needs to force the path to 
both .desktop files (if they provide.  them)

Thanks to all for your suggestions, I think I'll rename the binary in amap-thc, 
 avoiding this kind of troubles (and maybe also moving in /sbin).

I need to prior check how many packages needs it and how they run it, bt seems 
the most trivial task to do.

I'm on smartphone, I'll answer to everybody asap, I would like to avoid top 
posting.
(I answered to this first since I'm pretty sure having two different binaries 
with the same filename on the PATH can lead to confusion, but I might be wrong 
somewhere)

Thanks for clarifying

Gianfranco
Sent from Yahoo Mail on Android

Re: Bug#753704: ITP: amap -- Next-generation scanning tool for pentesters

[Vincent Bernat]

 ❦  6 juillet 2014 10:56 +0200, Javier Fernandez-Sanguino  :

> Since 'amap' (the scanner) probably needs permission to make raw
> sockets to work properly (just like nmap) for some scans, why not
> install it in /usr/sbin/? That way there would be no conflict with the
> other package.

This has already been discussed for ax25-node vs nodejs. This solution
was proposed (and also implemented for some time). It has been ruled
that this is not an acceptable solution. The solution is to rename the
binary, eventually both of them if no agreement is found. In the case of
ax25-node and nodejs, it has been accepted a node-legacy package
providing "node" binary but only because this is an interpreter.
-- 
panic("mother...");
2.2.16 /usr/src/linux/drivers/block/cpqarray.c


signature.asc
Description: PGP signature

Re: Bug#753704: ITP: amap -- Next-generation scanning tool for pentesters

[Javier Fernandez-Sanguino]

El 05/07/2014 16:47, "Ralf Treinen"  escribió:
>
> On Sat, Jul 05, 2014 at 09:01:45PM +0900, Charles Plessy wrote:
> > > > Il Sabato 5 Luglio 2014 13:03, Charles Plessy 
ha scritto:
> > > >
> > > > The ‘amap-align’ package version 2.2-4 install the file ‘amap’ in
‘/usr/bin’,
> > > > this is why I am worried about clashes.
> >
> > Le Sat, Jul 05, 2014 at 12:11:37PM +0100, Gianfranco Costamagna a écrit
:
> > >
> > > According to both popcons, and according to the fact that both of
them are
> > > really niche packages and in really different environments (one for
> > > penetration testing and the other for med science) how do you feel
about
> > > making them non-coinstallable?
> >
> > This violates the Policy's section 10.1, but it is still my favorite
solution
> > for the reason that you explained above.
>
> I don't agree, packages should not be in conflict when it can be easily
avoided
> by renaming files.
>

Renaming binaries is confusing for end users.

Since 'amap' (the scanner)  probably needs permission to make raw sockets
to work properly (just like nmap) for some scans, why not install it in
/usr/sbin/? That way there would be no conflict with the other package.

Regards

Javier

Re: Bug#753704: ITP: amap -- Next-generation scanning tool for pentesters

[Andreas Tille]

On Sat, Jul 05, 2014 at 04:37:16PM +0200, Ralf Treinen wrote:
> > 
> > This violates the Policy's section 10.1, but it is still my favorite 
> > solution
> > for the reason that you explained above.
> 
> I don't agree, packages should not be in conflict when it can be easily 
> avoided
> by renaming files.

+1


Andreas. 

-- 
http://fam-tille.de


-- 
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/20140706083335.gc26...@an3as.eu