Bug#722238: ITP: python-nose-testconfig -- test configuration plugin for nosetests

2013-09-09 Thread Thomas Goirand 
Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: python-nose-testconfig
  Version : 0.9
  Upstream Author : Jesse Noller 
* URL : https://pypi.python.org/pypi/nose-testconfig
* License : Apache-2.0
  Programming Lang: Python
  Description : test configuration plugin for nosetests

 nose-testconfig is a plugin to the nose test framework which provides a
 faculty for passing test-specific (or test-run specific) configuration data to
 the tests being executed.
 .
 Currently configuration files in the following formats are supported:
   * YAML (via python-yaml)
   * INI (via ConfigParser)
   * Pure Python (via Exec)
   * JSON
 .
 The plugin is meant to be flexible, ergo the support of exec'ing arbitrary
 Python files as configuration files with no checks. The default format is
 assumed to be ConfigParser ini-style format.
 .
 The plugin provides a method of overriding certain parameters from the command
 line (assuming that the main "config" object is a dict) and can easily have
 additional parsers added to it.
 .
 A configuration file may not be provided. In this case, the config object is an
 emtpy dict. Any command line "overriding" paramters will be added to the dict.


-- 
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/20130909102123.8604.66938.report...@buzig.gplhost.com

Bug#722266: ITP: libccd -- libccd is library for collision detection between two convex shapes

2013-09-09 Thread Leopold Palomo-Avellaneda 
Package: wnpp
Severity: wishlist
Owner: "Leopold Palomo-Avellaneda" 

* Package name: libccd
  Version : 1.4
  Upstream Author : Daniel Fiser
* URL : http://libccd.danfis.cz/
* License : 3-clause BSD 
  Programming Lang: C
  Description : libccd is library for collision detection between two 
convex shapes

libccd implements variation on Gilbert-Johnson-Keerthi (GJK) algorithm +
Expand Polytope Algorithm (EPA). It also implements Minkowski Portal
Refinement (MPR, a.k.a. XenoCollide) algorithm as published in Game
Programming Gems 7. libccd is the only available open source library of my
knowledge that include MPR algorithm working in 3-D space. 


-- 
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/20130909150230.11220.52356.report...@soho.upc.es

Bug#722268: ITP: fcl -- The Flexible Collision Library

2013-09-09 Thread Leopold Palomo-Avellaneda 
Package: wnpp
Severity: wishlist
Owner: "Leopold Palomo-Avellaneda" 

* Package name: fcl
  Version : 0.2.9
  Upstream Author : Willow Garage, Inc.
* URL : https://github.com/flexible-collision-library
* License : BSD
  Programming Lang: C++
  Description : The Flexible Collision Library

This library includes various techniques for efficient collision detection
and proximity computation. Supported shapes are sphere, box, cone, cylinder 
and mesh.


-- 
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/20130909151900.11550.98008.report...@soho.upc.es

Re: [Popcon-developers] Encrypted popcon submissions

2013-09-09 Thread Ian Jackson 
Bill Allombert writes ("Re: [Popcon-developers] Encrypted popcon submissions"):
> I just released popularity-contest 1.60 with encryption enabled by default.

Well done.

Thanks,
Ian.


-- 
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/21037.58115.718818.367...@chiark.greenend.org.uk

Bug#722273: ITP: ruby-macaddr -- mac address determination for ruby

2013-09-09 Thread Thomas Bechtold 
Package: wnpp
Severity: wishlist
Owner: Thomas Bechtold 

* Package name: ruby-macaddr
  Version : 1.6.1
  Upstream Author : Ara T. Howard
* URL : http://rubygems.org/gems/macaddr
* License : Ruby
  Programming Lang: Ruby
  Description : mac address determination for ruby

Cross platform mac address determination for ruby.


-- 
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/20130909162032.24327.50956.reportbug@rosmarin

Bug#722274: ITP: ruby-base62 -- Integer#base62_encode instance method to encode an integer

2013-09-09 Thread Thomas Bechtold 
Package: wnpp
Severity: wishlist
Owner: Thomas Bechtold 

* Package name: ruby-base62
  Version : 0.1.4
  Upstream Author : JT Zemp, Saadiq Rodgers-King, Derrick Camerino
* URL : http://rubygems.org/gems/base62
* License : MIT
  Programming Lang: Ruby
  Description : Integer#base62_encode instance method to encode an integer

Base62 monkeypatches Integer to add an Integer#base62_encode instance method to 
encode an integer in the character set of 0-9 + A-Z + a-z. It also 
monkeypatches String to add String#base62_decode to take the string and turn it 
back into a valid integer.


-- 
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/20130909162547.26393.98452.reportbug@rosmarin

Re: overriding udev rules

2013-09-09 Thread Lennart Poettering 
On Mon, 26.08.13 01:22, Thomas Goirand (z...@debian.org) wrote:

> 
> On 08/24/2013 03:53 PM, Ben Hutchings wrote:
> > There is a very clear standard that distinguishes globally and locally
> > administered addresses.
> > 
> > While you would possibly to buy your own OUI and make global assignments
> > to your VMs, I seriously doubt you are doing that.  Don't steal address
> > space.
> > 
> > Ben.
> 
> By reading the above, I don't think I made myself clear enough.
> 
> In the case of a bare-metal driver for cloud computing IaaS, you would
> an have operating system image that could be booted once on one physical
> machine, then shutdown and later restarted on another hardware. In such
> use case, physical hardware is used to run the virtual machine images
> without virtualization. It is *not possible to choose the MAC*, as this
> is the one that is physically in the hardware, though udev should
> continue to behave "as if it was a virtual machine MAC address".
> 
> Therefore, I think there should be an easy, documented way, of telling
> udev to behave one way or another. I'd say /etc/udev/udev.conf could be
> the correct place to configure this. If we want to keep the current
> behavior of double-guessing the use case of the network interface (which
> I recognize is the most useful case), then it could stay as default, as
> long as there is a reliable way to configure udev.

systemd/udev upstream do not assign "persistent" fixed names anymore to
network interfaces, in order not to race against the kernel. Instead we
now assign predictable names insteads, which avoids the whole issue.

See 
http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/

The resulting names are somtimes a bit ugly, but predictable and stable,
and do not change on every VM reboot...

It's now a Debianism to stick to the persistant names, all support for
it has been removed upstream. From upstream we hope DEbian eventually
drops support for the old persistant names too.

As a side note, also note that the MAC address range definitions are all
blurred these days, MAC addresses are reused by manufacturers and most
parsable meaning of MAC addresses has been removed (simply because the
namespace is mostly depleted these days...)

Lennart

-- 
Lennart Poettering - Red Hat, Inc.


-- 
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/20130909185048.ga6...@tango.0pointer.de

Re: overriding udev rules

2013-09-09 Thread Michael Biebl 
Hi Lennart,

Am 09.09.2013 20:50, schrieb Lennart Poettering:
> It's now a Debianism to stick to the persistant names, all support for
> it has been removed upstream. From upstream we hope DEbian eventually
> drops support for the old persistant names too.

We (Debian pkg-systemd team) decided to keep the old persistent naming
scheme "as default" for now, for the simple reason, that we didn't want
to break upgrades. It just didn't seem possible to detect every case
where the old ethX names were used and losing network connection as part
of the upgrade is a big no-go.
As documented in the debian changelog, you can opt-in to use the new
naming scheme, but this requires explicit configuration from the
administrator.
We might make the new network interface naming the default for new
installations, but this isn't something we haven't been working on yet.

Cheers,
Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: overriding udev rules

2013-09-09 Thread Kay Sievers 
On Mon, Sep 9, 2013 at 11:48 PM, Michael Biebl  wrote:
> Am 09.09.2013 20:50, schrieb Lennart Poettering:
>> It's now a Debianism to stick to the persistant names, all support for
>> it has been removed upstream. From upstream we hope DEbian eventually
>> drops support for the old persistant names too.
>
> We (Debian pkg-systemd team) decided to keep the old persistent naming
> scheme "as default" for now, for the simple reason, that we didn't want
> to break upgrades. It just didn't seem possible to detect every case
> where the old ethX names were used and losing network connection as part
> of the upgrade is a big no-go.
> As documented in the debian changelog, you can opt-in to use the new
> naming scheme, but this requires explicit configuration from the
> administrator.
> We might make the new network interface naming the default for new
> installations, but this isn't something we haven't been working on yet.

Hmm, why would upgrades break?

The old file would still be there, rename the devices (if you keep the
patch to swap names, which upstream does not support any more), and
take precedence over tht new names;  the old rules file would just not
be updated anymore when new devices appear.

Kay


-- 
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/capxgp13syupgweorgm6xmvrvqrqpzafdbf3bxp1sb-abstj...@mail.gmail.com

Re: overriding udev rules

2013-09-09 Thread Kay Sievers 
On Mon, Sep 9, 2013 at 11:26 PM, Ben Hutchings  wrote:
> On Mon, Sep 09, 2013 at 08:50:48PM +0200, Lennart Poettering wrote:
> [...]
>> As a side note, also note that the MAC address range definitions are all
>> blurred these days, MAC addresses are reused by manufacturers and most
>> parsable meaning of MAC addresses has been removed (simply because the
>> namespace is mostly depleted these days...)
>
> There is no shortage of namespace; only a tiny fraction of the 2^22
> valid OUIs have been allocated.  But perhaps some OUIs are abused for
> volatile and non-unique assignments and you're right that this breaks
> the old naming policy.
>
> The new udev policy isn't any better for Thomas's use case, though.
> He seems to want to take his chances with kernel probing order...

It's hopefully still better for most virtual machine use cases, as it
will not write out config to disk at every boot and not use MAC
addresses, which can change from boot-to-boot on some boxes.

With the old model we've seen virtual machines with 1000s of entries
in the rules files created by just rebooting them. :)

Kay


-- 
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/capxgp11wppj6kenbbiudywppyae_tk2x-hn2hcjto19apt7...@mail.gmail.com

Re: overriding udev rules

2013-09-09 Thread Michael Biebl 
Hi Kay,

Am 09.09.2013 23:53, schrieb Kay Sievers:
> Hmm, why would upgrades break?

See [1], there are several cases where 75-persistent-net-generator.rules
doesn't generate a persistent name (mostly VM related). In those cases,
you would typically use eth0 in your /etc/network/interface etc.
On upgrades, the new networking naming would kick in, and suddenly it's
no longer eth0.

Michael


[1]
http://anonscm.debian.org/gitweb/?p=pkg-systemd/systemd.git;a=blob;f=debian/extra/rules/75-persistent-net-generator.rules;h=b6fcb917ee220b6ec6305b7170680caac3f0acdd;hb=refs/heads/debian-experimental#l27
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: overriding udev rules

2013-09-09 Thread Michael Biebl 
Hi Kay,

Am 09.09.2013 23:53, schrieb Kay Sievers:
> Hmm, why would upgrades break?

See [1], there are several cases where 75-persistent-net-generator.rules
doesn't generate a persistent name (mostly VM related). In those cases,
you would typically use eth0 in your /etc/network/interface etc.
On upgrades, the new networking naming would kick in, and suddenly it's
no longer eth0.

Michael


[1]
http://anonscm.debian.org/gitweb/?p=pkg-systemd/systemd.git;a=blob;f=debian/extra/rules/75-persistent-net-generator.rules;h=b6fcb917ee220b6ec6305b7170680caac3f0acdd;hb=refs/heads/debian-experimental#l27
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: overriding udev rules

2013-09-09 Thread Ben Hutchings 
On Mon, Sep 09, 2013 at 08:50:48PM +0200, Lennart Poettering wrote:
[...]
> As a side note, also note that the MAC address range definitions are all
> blurred these days, MAC addresses are reused by manufacturers and most
> parsable meaning of MAC addresses has been removed (simply because the
> namespace is mostly depleted these days...)

There is no shortage of namespace; only a tiny fraction of the 2^22
valid OUIs have been allocated.  But perhaps some OUIs are abused for
volatile and non-unique assignments and you're right that this breaks
the old naming policy.

The new udev policy isn't any better for Thomas's use case, though.
He seems to want to take his chances with kernel probing order...

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
  - Albert Camus


-- 
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/20130909212630.gk7...@decadent.org.uk

Re: overriding udev rules

2013-09-09 Thread Kay Sievers 
On Tue, Sep 10, 2013 at 12:00 AM, Michael Biebl  wrote:
> Am 09.09.2013 23:53, schrieb Kay Sievers:
>> Hmm, why would upgrades break?
>
> See [1], there are several cases where 75-persistent-net-generator.rules
> doesn't generate a persistent name (mostly VM related). In those cases,
> you would typically use eth0 in your /etc/network/interface etc.
> On upgrades, the new networking naming would kick in, and suddenly it's
> no longer eth0.

The new names should only get active where the old rules also matched,
it currently supports PCI parent devices only, most VM use cases, xen,
virt drivers would be excluded anyway.

But sure, there can be setups where that could happen, I would just
expect that the number is very very low.

Kay


-- 
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/capxgp11nncysl1xrwm+z2ux5aukomkpodxothqro8dps1qi...@mail.gmail.com

Re: overriding udev rules

2013-09-09 Thread Russ Allbery 
Kay Sievers  writes:
> On Mon, Sep 9, 2013 at 11:48 PM, Michael Biebl  wrote:

>> We (Debian pkg-systemd team) decided to keep the old persistent naming
>> scheme "as default" for now, for the simple reason, that we didn't want
>> to break upgrades. It just didn't seem possible to detect every case
>> where the old ethX names were used and losing network connection as
>> part of the upgrade is a big no-go.

>> As documented in the debian changelog, you can opt-in to use the new
>> naming scheme, but this requires explicit configuration from the
>> administrator.

>> We might make the new network interface naming the default for new
>> installations, but this isn't something we haven't been working on yet.

> Hmm, why would upgrades break?

> The old file would still be there, rename the devices (if you keep the
> patch to swap names, which upstream does not support any more), and take
> precedence over tht new names; the old rules file would just not be
> updated anymore when new devices appear.

Manually-deployed /etc/network/interfaces files that assume a specific
device naming come to mind.  We have tons of those at work.

-- 
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/87txhtskxc@windlord.stanford.edu

new persistent network interface naming [Re: overriding udev rules]

2013-09-09 Thread Michael Biebl 
Am 10.09.2013 00:05, schrieb Kay Sievers:
> On Tue, Sep 10, 2013 at 12:00 AM, Michael Biebl  wrote:
>> Am 09.09.2013 23:53, schrieb Kay Sievers:
>>> Hmm, why would upgrades break?
>>
>> See [1], there are several cases where 75-persistent-net-generator.rules
>> doesn't generate a persistent name (mostly VM related). In those cases,
>> you would typically use eth0 in your /etc/network/interface etc.
>> On upgrades, the new networking naming would kick in, and suddenly it's
>> no longer eth0.
> 
> The new names should only get active where the old rules also matched,
> it currently supports PCI parent devices only, most VM use cases, xen,
> virt drivers would be excluded anyway.
> 
> But sure, there can be setups where that could happen, I would just
> expect that the number is very very low.

Ok, thanks for the input.
The new network interface naming is certainly an interesting approach
and probably a better one then what we currently use (in Debian).
That said, we didn't want to tackle this issue at this point but rather
focus on getting v204 into sid/testing.
We will certainly revisit this decision when we have time for it, it's
definitely not set in stone. We just wanted to avoid having to deal with
the (possible) fallout at the current stage.

Cheers,
Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: overriding udev rules

2013-09-09 Thread Uoti Urpala 
Russ Allbery wrote:
>Kay Sievers  writes:
> > Hmm, why would upgrades break?
> 
> > The old file would still be there, rename the devices (if you keep the
> > patch to swap names, which upstream does not support any more), and take
> > precedence over tht new names; the old rules file would just not be
> > updated anymore when new devices appear.
> 
> Manually-deployed /etc/network/interfaces files that assume a specific
> device naming come to mind.  We have tons of those at work.

Why would those break? Just having a manually-deployed
/etc/network/interfaces file that uses names like "eth0" should not
break upgrades, because as mentioned in the part you quoted, the
existing already-generated rules should still trigger and keep renaming
the same card to eth0. So you need to assume something more to have an
example of a problem case.



-- 
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/1378769281.30447.8.camel@glyph.nonexistent.invalid

Re: overriding udev rules

2013-09-09 Thread Patrick Lauer 
On 09/10/2013 02:50 AM, Lennart Poettering wrote:
> On Mon, 26.08.13 01:22, Thomas Goirand (z...@debian.org) wrote:
> 
>>
>> On 08/24/2013 03:53 PM, Ben Hutchings wrote:
>>> There is a very clear standard that distinguishes globally and locally
>>> administered addresses.
>>>
>>> While you would possibly to buy your own OUI and make global assignments
>>> to your VMs, I seriously doubt you are doing that.  Don't steal address
>>> space.
>>>
>>> Ben.
>>
>> By reading the above, I don't think I made myself clear enough.
>>
>> In the case of a bare-metal driver for cloud computing IaaS, you would
>> an have operating system image that could be booted once on one physical
>> machine, then shutdown and later restarted on another hardware. In such
>> use case, physical hardware is used to run the virtual machine images
>> without virtualization. It is *not possible to choose the MAC*, as this
>> is the one that is physically in the hardware, though udev should
>> continue to behave "as if it was a virtual machine MAC address".
>>
>> Therefore, I think there should be an easy, documented way, of telling
>> udev to behave one way or another. I'd say /etc/udev/udev.conf could be
>> the correct place to configure this. If we want to keep the current
>> behavior of double-guessing the use case of the network interface (which
>> I recognize is the most useful case), then it could stay as default, as
>> long as there is a reliable way to configure udev.
> 
> systemd/udev upstream do not assign "persistent" fixed names anymore to
> network interfaces, in order not to race against the kernel. Instead we
> now assign predictable names insteads, which avoids the whole issue.
> 
> See 
> http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
> 
> The resulting names are somtimes a bit ugly, but predictable and stable,
> and do not change on every VM reboot...

They are predictable from within a booted linux install with a new kernel.

They are stable as long as the kernel and the hardware do not change too
much; e.g. enabling the "other" graphics card in a hybrid setup
sometimes adds a PCIe bus, so all names shift around.

There are still race conditions.


> 
> It's now a Debianism to stick to the persistant names, all support for
> it has been removed upstream. From upstream we hope DEbian eventually
> drops support for the old persistant names too.
> 
> As a side note, also note that the MAC address range definitions are all
> blurred these days, MAC addresses are reused by manufacturers and most
> parsable meaning of MAC addresses has been removed (simply because the
> namespace is mostly depleted these days...)

Reusing would be extremely bad - Medion once shipped a few charges of
machines with the same MACs on all, so people that bought more than one
had fascinating network failures. I hope no vendor is *THAT* insane and
still allowed to assign MACs.


-- 
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/522e6270.1010...@gentoo.org

Bug#722308: ITP: abx -- audio ABX testing software

2013-09-09 Thread Chow Loong Jin 
Package: wnpp
Severity: wishlist
Owner: Chow Loong Jin 

* Package name: abx
  Version : 0.0~b1
  Upstream Author : Petteri Hintsanen 
* URL : http://phintsan.kapsi.fi/abx.html
* License : GPL-3+
  Programming Lang: C
  Description : audio ABX testing software

 abx is a program for performing software-based audio ABX testing on GNU/Linux
 systems. ABX test (Wikipedia, Hydrogenaudio) is a statistical test for
 assessing whether you are able to tell for audible differences between two
 samples. For example, one sample can be a compressed audio file such as OGG
 Vorbis file and another one its uncompressed variant (WAV, AU, …). You can then
 use abx to infer whether you are able to separate the two samples due to
 compression artifacts.

-- 
Kind regards,
Loong Jin


signature.asc
Description: Digital signature

Bug#722309: ITP: minetest-mod-itemdrop -- Minetest mod - Item Drop

2013-09-09 Thread Dominik George 
Package: wnpp
Severity: wishlist
Owner: Dominik George 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: minetest-mod-itemdrop
  Upstream Author : PilzAdam 
* License : WTFPL
  Programming Lang: Lua
  Description : Minetest mod - Item Drop

 This mod adds Minecraft like drop/pick up of items to Minetest.
 .
 You can drop any item from your inventory and other players can
 pick it up, adding it to their inventory.
 .
 Several other mods use item_drop, e.g. the technic mod.

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

iQJOBAEBCAA4BQJSLr3aMRpodHRwczovL3d3dy5kb21pbmlrLWdlb3JnZS5kZS9n
cGctcG9saWN5LnR4dC5hc2MACgkQt5o8FqDE8pbsHRAAv0j4gVWuIGYT3Lu9mj/l
Kfp27LgJklWpdr0ABIjQhWrnEv9R4NBAiTAFbAMJh86+L70NRrqZmd6+R+tpvsEv
XmXY9SxbJp5qIkc777rqf7AwNTi0L4tqCiexyeFSxURVFaOGgy1LNnAF+4aQ+muA
lEWwDXfW5QGgAdzE4fqmSKnXijk/murq2c0zfus4Lyi2Cx1jA+aS78e+AVUOqjXa
dv4i4ifzz58U7JZGeJojFQnvLXx2EGx/TKXAWEBAn6KiEIGQ+cLPbxlkzhZuV8Xr
gwu/RWvZLrme6EIR3xeXgqWnmL+6RcUDrUGkNguIAhuOAUsZmQGnco2GCDEbgvSU
fUrU2hGBuum7+/1aEi341dIbXg8/x7fbCLm9rNwy25hMHmu7Ckw6gFmv3aIg97VW
XDrChllQdq6XGRdlvoBGckJx0AqdjKKobck9ZOJBm4DPyI2GpBRocKMLlVv4Ueju
MNw3KhuUVHU3cgf6UE0wghBs2CUKpzrEMgfjT9FAdYHSNEfe6e1ioiuejeUyI3DQ
/9gibjYkywVsyEeDLH0TEj7GEQztXRTILhYpA+dHNyZgQGfZjRKnOfJxh0GkExVz
AQxc7WH0ysIs1JdqOlFhcmLOAhdYsH2ml3WXDcReaRCYwcpOlMI2t9tWhzGFOKBp
Vbp73g2qfdkB/F6BqP855dc=
=U2LO
-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/20130910063610.32555.89440.report...@keks.lan.naturalnet.de