Bug#822096: ITP: scapy3k -- Python 3 packet generator/sniffer and network scanner/discovery

2016-04-21 Thread Iain R. Learmonth
Package: wnpp
Severity: wishlist
Owner: "Iain R. Learmonth" 

* Package name: scapy3k
  Version : 0.18
  Upstream Author : Eriks Dobelis 
* URL : https://github.com/phaethon/scapy
* License : GPL-2
  Programming Lang: Python
  Description : Python 3 packet generator/sniffer and network 
scanner/discovery

Scapy is a powerful interactive packet manipulation tool, packet generator,
network scanner, network discovery, packet sniffer, etc. It can for the
moment replace hping, 85% of nmap, arpspoof, arp-sk, arping, tcpdump,
tethereal, p0f, 

In scapy you define a set of packets, then it sends them, receives answers,
matches requests with answers and returns a list of packet couples (request,
answer) and a list of unmatched packets. This has the big advantage over
tools like nmap or hping that an answer is not reduced to
(open/closed/filtered), but is the whole packet.



This package is to be maintained within the Internet Measurement
Packaging Team .

This packaging work is being performed as part of the European Union's
Horizon 2020 project MAMI. This project has received funding from the
European Union's Horizon 2020 research and innovation programme under
grant agreement No 688421. The opinions expressed and arguments employed
reflect only the authors' view. The European Commission is not
responsible for any use that may be made of that information.

-- 



Bug#822141: ITP: libgovirt -- GObject-based library to access oVirt REST API

2016-04-21 Thread Laurent Bigonville
Package: wnpp
Severity: wishlist
Owner: Laurent Bigonville 

* Package name: libgovirt
  Version : 0.3.4
  Upstream Author : Christophe Fergeau 
Fabiano Fidêncio 
* License : LGPL
  Programming Lang: C
  Description : GObject-based library to access oVirt REST API

libgovirt is a GObject-based library to access oVirt REST API. It uses
GObject and librest to integrate well with GNOME applications.

>From the README:

GoVirt is a GObject wrapper for the oVirt REST API [1]. It will
only provide very basic functionality as the goal is to
autogenerate a full wrapper as it is already done for the python
bindings.

NB: at this time, govirt is *NOT* considered API/ABI stable. Future
releases may still include API/ABI incompatible changes.



Seriously, these binaries should be stripped by default

2016-04-21 Thread Steve McIntyre
Control: severity -1 serious
Justification: wasting many megabytes of space and download

We're shipping broken toolchain packages that are intentionally too
large, and this is causing issues elsewhere. The "netinst" CD image
that we advertise to people as the default Debian image to use for
most installations is now huge. The multi-arch netinst no longer even
fits on a single CD due to this waste of space.

There's not been any visible progress on this bug in since last
year. If upstream want to ship uncompressed binaries for diagnostics
and can't cope with separate debug symbols, maybe ship separate
alternative unstripped toolchain packages and point to those if people
want them?

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"When C++ is your hammer, everything looks like a thumb." -- Steven M. Haflich



gcc-on-diet (was Re: Seriously, these binaries should be stripped by default)

2016-04-21 Thread Guillem Jover
Hi!

On Thu, 2016-04-21 at 18:28:59 +0100, Steve McIntyre wrote:
> Control: severity -1 serious
> Justification: wasting many megabytes of space and download

Yes.

> We're shipping broken toolchain packages that are intentionally too
> large, and this is causing issues elsewhere. The "netinst" CD image
> that we advertise to people as the default Debian image to use for
> most installations is now huge. The multi-arch netinst no longer even
> fits on a single CD due to this waste of space.

And meanwhile, as I mentioned on the bug report. for anyone who cannot
tolerate either the current situation, I cooked a low-fat/light/zero
workaround at:

  

If there's demand and no one else does it I could perhaps be bothered
to create a proper Debian repo somewhere, maybe. :)

Thanks,
Guillem



Re: Bug#783876: Seriously, these binaries should be stripped by default

2016-04-21 Thread Matthias Klose

Control: severity -1 important

On 21.04.2016 19:28, Steve McIntyre wrote:

Control: severity -1 serious
Justification: wasting many megabytes of space and download


sorry, I don't see this as a justification.


We're shipping broken toolchain packages


please stop trolling. Nothing is broken.

No, we don't ship these, as clearly stated in this report. They are in the 
archive as unstripped versions.  Other software stacks as the Go stack ship 
unstripped binaries as well, because they need these.



that are intentionally too
large, and this is causing issues elsewhere. The "netinst" CD image
that we advertise to people as the default Debian image to use for
most installations is now huge. The multi-arch netinst no longer even
fits on a single CD due to this waste of space.


So why does the netinst image need a compiler?


There's not been any visible progress on this bug in since last
year. If upstream want to ship uncompressed binaries for diagnostics
and can't cope with separate debug symbols, maybe ship separate
alternative unstripped toolchain packages and point to those if people
want them?


The unstripped binaries should be installed by default on porter boxes and 
buildds.  Yes, this is a trade-off between (largely my) developer time, the 
ability for Debian developers to produce complete bug reports, and an increase 
on machine/bandwidth resources.  If I have the choice to select between human 
and other resources, I'll try to keep the time I have to spend on reproducing 
things rather small.


> There's not been any visible progress on this bug in since last
> year.

So you step in here like a bull in a china shop, raising the severity without 
doing anything else?  You are working for a Linux and open source aware 
organization, have you tried to get developer time to address issues like these? 
 Have you sent a patch proposal to implement such a change either upstream or 
on the packaging side?


Not that amused, Matthias



Bug#822183: ITP: crossbar -- WAMP application router

2016-04-21 Thread Orestis Ioannou
Package: wnpp
Severity: wishlist
Owner: Orestis Ioannou 

* Package name: crossbar
  Version : 0.13.2
  Upstream Author : Tavendo GmbH
* URL : http://crossbar.io/
* License : AGPL-3
  Programming Lang: Python
  Description : WAMP application router

Crossbar.io is a networking platform for distributed and microservice
applications.
It is feature rich, scalable, robust and secure.
It takes care of the hard parts of messaging so you can focus on your app's
features.

For the moment the archive is missing the following dependencies:

python{3}-pytrie
python{3}-sdnotify
python{3}-shutilwhich
python{3}-treq
python{3}-wsaccel
python3-autobahn

I'll probably maintain this in collab-maint.



Re: Bug#783876: Seriously, these binaries should be stripped by default

2016-04-21 Thread Steve McIntyre
On Thu, Apr 21, 2016 at 11:23:41PM +0200, Matthias Klose wrote:
>On 21.04.2016 20:08, Ondřej Surý wrote:
>>>From reading the bug comments I can see both sides of the argument, so
>>why we don't ship just two versions that would be exchangeable - one
>>with symbols and one (default) stripped?
>>
>>The stripped one would be installed by default and if you need to
>>produce trace, you would install the second variant. GCC plugins also
>>could depend on unstripped variant of the package. That would provide
>>both parties what they need.
>
>so how do the unstripped ones get installed by default on porter boxes? How
>are the unstripped ones installed on the buildds by default?

By talking to the admins of those boxes, maybe? The setup on those is
already heavily scripted, so hopefully shouldn't be too difficult to
adapt.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"We're the technical experts.  We were hired so that management could
 ignore our recommendations and tell us how to do our jobs."  -- Mike Andrews



Bug#822193: ITP: treq -- HTTP library inspired by requests but written on top of Twisted

2016-04-21 Thread Orestis Ioannou
Package: wnpp
Severity: wishlist
Owner: Orestis Ioannou 

* Package name: treq
  Version : 15.1.0
  Upstream Author : David Reid
* URL : http://treq.readthedocs.org
* License : MIT
  Programming Lang: Python
  Description : HTTP library inspired by requests but written on top of
Twisted

It provides a simple, higher level API for making HTTP requests when using
Twisted.

>>> from treq import get

>>> def done(response):
... print response.code
... reactor.stop()

>>> get("http://www.github.com";).addCallback(done)

>>> from twisted.internet import reactor
>>> reactor.run()
200


Besides this being a useful library i need it as a dependency for crossbar.
I intend to package this under the umbrella of the python modules team.



Re: Bug#783876: Seriously, these binaries should be stripped by default

2016-04-21 Thread Steve McIntyre
On Thu, Apr 21, 2016 at 11:40:34PM +0200, Matthias Klose wrote:
>Control: severity -1 important
>
>On 21.04.2016 19:28, Steve McIntyre wrote:
>>Control: severity -1 serious
>>Justification: wasting many megabytes of space and download
>
>sorry, I don't see this as a justification.
>
>>We're shipping broken toolchain packages
>
>please stop trolling. Nothing is broken.

Thanks for the insult. :-(

There's no trolling here - they're broken according to policy ("by
default all installed binaries should be stripped"), and this change
is causing real problems for people.

>>that are intentionally too
>>large, and this is causing issues elsewhere. The "netinst" CD image
>>that we advertise to people as the default Debian image to use for
>>most installations is now huge. The multi-arch netinst no longer even
>>fits on a single CD due to this waste of space.
>
>So why does the netinst image need a compiler?

It's been a feature for years that we include a compiler and kernel
headers to allow people to build third party modules on amd64/i386.

>>There's not been any visible progress on this bug in since last
>>year. If upstream want to ship uncompressed binaries for diagnostics
>>and can't cope with separate debug symbols, maybe ship separate
>>alternative unstripped toolchain packages and point to those if people
>>want them?
>
>The unstripped binaries should be installed by default on porter boxes and
>buildds.  Yes, this is a trade-off between (largely my) developer time, the
>ability for Debian developers to produce complete bug reports, and an
>increase on machine/bandwidth resources.  If I have the choice to select
>between human and other resources, I'll try to keep the time I have to spend
>on reproducing things rather small.

With separate -unstripped (or whatever) packages, they could be
installed by admin choice in those situations.

>> There's not been any visible progress on this bug in since last
>> year.
>
>So you step in here like a bull in a china shop, raising the severity without
>doing anything else?  You are working for a Linux and open source aware
>organization, have you tried to get developer time to address issues like
>these?  Have you sent a patch proposal to implement such a change either
>upstream or on the packaging side?

Please don't go there. We're all busy, you know that.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Google-bait:   http://www.debian.org/CD/free-linux-cd
  Debian does NOT ship free CDs. Please do NOT contact the mailing
  lists asking us to send them to you.



Re: Bug#783876: Seriously, these binaries should be stripped by default

2016-04-21 Thread Steve McIntyre
On Thu, Apr 21, 2016 at 11:31:46PM +0100, Steve McIntyre wrote:
>On Thu, Apr 21, 2016 at 11:40:34PM +0200, Matthias Klose wrote:
>>
>>The unstripped binaries should be installed by default on porter boxes and
>>buildds.  Yes, this is a trade-off between (largely my) developer time, the
>>ability for Debian developers to produce complete bug reports, and an
>>increase on machine/bandwidth resources.  If I have the choice to select
>>between human and other resources, I'll try to keep the time I have to spend
>>on reproducing things rather small.
>
>With separate -unstripped (or whatever) packages, they could be
>installed by admin choice in those situations.

Following up a bit more - I understand what you've done here, and I
understand what you're trying to achieve here. Would you accept
patches to add -unstripped versions to the packaging if they were
offered?

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"Because heaters aren't purple!" -- Catherine Pitt



Re: Bug#783876: Seriously, these binaries should be stripped by default

2016-04-21 Thread Matthias Klose

On 22.04.2016 00:31, Steve McIntyre wrote:

On Thu, Apr 21, 2016 at 11:40:34PM +0200, Matthias Klose wrote:

So why does the netinst image need a compiler?


It's been a feature for years that we include a compiler and kernel
headers to allow people to build third party modules on amd64/i386.


ok, thanks for the explanation.


There's not been any visible progress on this bug in since last
year. If upstream want to ship uncompressed binaries for diagnostics
and can't cope with separate debug symbols, maybe ship separate
alternative unstripped toolchain packages and point to those if people
want them?


The unstripped binaries should be installed by default on porter boxes and
buildds.  Yes, this is a trade-off between (largely my) developer time, the
ability for Debian developers to produce complete bug reports, and an
increase on machine/bandwidth resources.  If I have the choice to select
between human and other resources, I'll try to keep the time I have to spend
on reproducing things rather small.


With separate -unstripped (or whatever) packages, they could be
installed by admin choice in those situations.


well, admin choice is usually not the default. So this would miss the buildds.

you didn't write about how much the netinst image exceeds the cd size.  If it 
helps, lto1 could be stripped by default, because it's not used by default for 
package builds.


Matthias



Re: Bug#783876: Seriously, these binaries should be stripped by default

2016-04-21 Thread Samuel Thibault
Matthias Klose, on Fri 22 Apr 2016 00:47:09 +0200, wrote:
> >With separate -unstripped (or whatever) packages, they could be
> >installed by admin choice in those situations.
> 
> well, admin choice is usually not the default. So this would miss the buildds.

Making the buildds install extra packages & such is not very difficult.
It's a matter of changing the sbuild behavior for buildd chroots.

Samuel



Re: Bug#783876: Seriously, these binaries should be stripped by default

2016-04-21 Thread Steve McIntyre
On Fri, Apr 22, 2016 at 12:47:09AM +0200, Matthias Klose wrote:
>
>you didn't write about how much the netinst image exceeds the cd size.  If it
>helps, lto1 could be stripped by default, because it's not used by default
>for package builds.

Looking for about 70MB to (just) squeeze into 1 CD again.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"This dress doesn't reverse." -- Alden Spiess



Work-needing packages report for Apr 22, 2016

2016-04-21 Thread wnpp
The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.

Total number of orphaned packages: 721 (new: 2)
Total number of packages offered up for adoption: 187 (new: 2)
Total number of packages requested help for: 45 (new: 0)

Please refer to http://www.debian.org/devel/wnpp/ for more information.



The following packages have been orphaned:

   gnurobots (#821116), orphaned 6 days ago
 Installations reported by Popcon: 194

   polygraph (#821729), orphaned 3 days ago
 Description: performance testing tool for caching proxies and more
 Installations reported by Popcon: 12

719 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/orphaned for a complete list.



The following packages have been given up for adoption:

   gl2ps (#822161), offered today
 Reverse Depends: avogadro drawxtl gabedit gfsview gmsh ifrit
   libgfsgl0 libgl2ps-dev libgl2ps0-dbg liboce-visualization-dev (17
   more omitted)
 Installations reported by Popcon: 10490

   ruby-mime (#822205), offered today
 Reverse Depends: cewl
 Installations reported by Popcon: 66

185 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list.



For the following packages help is requested:

   athcool (#278442), requested 4195 days ago
 Description: Enable powersaving mode for Athlon/Duron processors
 Installations reported by Popcon: 28

   awstats (#755797), requested 638 days ago
 Description: powerful and featureful web server log analyzer
 Installations reported by Popcon: 4167

   balsa (#642906), requested 1670 days ago
 Description: An e-mail client for GNOME
 Reverse Depends: balsa-dbg
 Installations reported by Popcon: 704

   cardstories (#624100), requested 1823 days ago
 Description: Find out a card using a sentence made up by another
   player
 Installations reported by Popcon: 5

   cups (#532097), requested 2511 days ago
 Description: Common UNIX Printing System
 Reverse Depends: bluez-cups boomaga chromium
   cinnamon-settings-daemon cloudprint cups cups-backend-bjnp
   cups-browsed cups-bsd cups-client (65 more omitted)
 Installations reported by Popcon: 170087

   cyrus-sasl2 (#799864), requested 211 days ago
 Description: authentication abstraction library
 Reverse Depends: 389-ds-base 389-ds-base-libs 389-dsgw adcli
   autofs-ldap cairo-dock-mail-plug-in claws-mail
   claws-mail-acpi-notifier claws-mail-address-keeper
   claws-mail-archiver-plugin (123 more omitted)
 Installations reported by Popcon: 192152

   developers-reference (#759995), requested 600 days ago
 Description: guidelines and information for Debian developers
 Installations reported by Popcon: 19305

   devscripts (#800413), requested 205 days ago
 Description: scripts to make the life of a Debian Package maintainer
   easier
 Reverse Depends: apt-build apt-listdifferences aptfs arriero
   bzr-builddeb customdeb debci debian-builder debmake debpear (27 more
   omitted)
 Installations reported by Popcon: 13166

   ejabberd (#767874), requested 535 days ago
 Description: distributed, fault-tolerant Jabber/XMPP server written
   in Erlang
 Reverse Depends: ejabberd-contrib ejabberd-mod-cron
   ejabberd-mod-log-chat ejabberd-mod-logsession ejabberd-mod-logxml
   ejabberd-mod-mam-mnesia ejabberd-mod-message-log
   ejabberd-mod-muc-log-http ejabberd-mod-post-log ejabberd-mod-rest (4
   more omitted)
 Installations reported by Popcon: 773

   fbcat (#565156), requested 2290 days ago
 Description: framebuffer grabber
 Installations reported by Popcon: 216

   freeipmi (#628062), requested 1792 days ago
 Description: GNU implementation of the IPMI protocol
 Reverse Depends: conman freeipmi freeipmi-bmc-watchdog
   freeipmi-ipmidetect freeipmi-ipmiseld freeipmi-tools ipmitool
   libfreeipmi-dev libfreeipmi16 libipmiconsole-dev (7 more omitted)
 Installations reported by Popcon: 6466

   freerdp (#799759), requested 212 days ago
 Description: RDP client for Windows Terminal Services (X11 client)
 Reverse Depends: freerdp-x11 freerdp-x11-dbg libfreerdp-cache1.1
   libfreerdp-client1.1 libfreerdp-codec1.1 libfreerdp-common1.1.0
   libfreerdp-core1.1 libfreerdp-crypto1.1 libfreerdp-dbg
   libfreerdp-dev (28 more omitted)
 Installations reported by Popcon: 73842

   gnat-gps (#496905), requested 2793 days ago
 Description: co-maintainer needed
 Reverse Depends: gnat-gps gnat-gps-dbg
 Installations reported by Popcon: 524

   g

Bug#822219: ITP: golang-github-docker-go -- Utility package for building other Docker packages

2016-04-21 Thread Potter, Tim (HPE Linux Support)
Package: wnpp
Severity: wishlist
Owner: Tim Potter 
X-Debbugs-CC: debian-devel@lists.debian.org, 
pkg-go-maintain...@lists.alioth.debian.org

* Package name: golang-github-docker-go
  Version : 0.0~git20160303.6.d30aec9-1
  Upstream Author : Docker
* URL : https://github.com/docker/go
* License : BSD-3-clause
  Programming Lang: Go
  Description : Utility package for building other Docker packages

 This packages is a fork of the canonical/json package and is used by
 other packages in the Docker ecosystem.


signature.asc
Description: Message signed with OpenPGP using GPGMail


ITP: flipcoin -- flip an adjustable coin for random exit status

2016-04-21 Thread Rudi Cilibrasi

Package: wnpp
Severity: wishlist
Owner: Rudi Cilibrasi 

* Package name: flipcoin
  Version : 1.0.0
  Upstream Author : Rudi Cilibrasi 
* URL : https://github.com/rudi-cilibrasi/flipcoin
* License : MIT/X
  Programming Lang: C
  Description : flip an adjustable coin for random exit status

This command-line utility can be used to simulate a coin flip to get
a random exit status.  The probability of success is adjustable using
an optional command line parameter.

The package includes a single binary executable and man page and is
easily buildable using autoconf and automake.

Although I was a Debian Developer ten years ago, I have not had time to
do much since having kids. I am hoping somebody else can take this
package and sign and upload it. I do not expect to make many revisions
because the source code and functionality are quite simple so the
maintenance burden should be almost zero in the future. I would
appreciate an adoption, co-maintainer, or sponsor as appropriate.

For your convenience, an initial lintian-clean Debian source package is
publicly available at:

https://github.com/rudi-cilibrasi/pkg-flipcoin

This package is a useful core utility for shell scripts that need to
do things in a way that is decorrelated in time and infrequent. Usage is
simple at the shell prompt:

if flipcoin ; then echo heads ; else echo tails ; fi