Bug#853770: unblock: pyro4

[GCS]

On Fri, Feb 3, 2017 at 11:11 PM, Emilio Pozuelo Monfort
 wrote:
> On 31/01/17 19:18, Laszlo Boszormenyi (GCS) wrote:
>> Which solution would be allowed for Stretch?
>
> bootstrap-vz depends on python2-pyro4, so we can't just drop it.
>
> I don't like 2, I'd rather add a new source than embed this inside pyro.
>
> Please upload selectors34 and I'll see about granting an exception to fix this
> RC bug.
 Both selectors34 and fixed pyro4 was uploaded some days ago - I let
them age a bit to reveal any issues. None so far, thus please unblock
both packages.

Thanks,
Laszlo/GCS

Bug#853770: unblock: pyro4

[Emilio Pozuelo Monfort]

On 31/01/17 19:18, Laszlo Boszormenyi (GCS) wrote:
> Package: release.debian.org
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Hi Release Team,
> 
> I don't want to hide that due to my mistake, pyro4 package migrated to
> Stretch without the selectors34 dependency of python2-pyro4 even
> packaged. It was only partly fixed with importing the selectors module
> instead[1] - that fixes the client mode but the multiplexed server
> still fails (the user have to change to the threadpool variant).
> 
> I see the following solutions:
> 1) Drop the python2 variant of Pyro4 and only ship the python3 one
>(worst case).
> 2) Allow the packaged selectors34 module[2] to Stretch (not yet
>uploaded) as it's an one file module.
> 3) Add the selectors34.py to the pyro4 package, debdiff to the Stretch
>version is attached.
> 4) Use the upstream commit not to fail with the import, but inform the
>user to switch to the threadpool variant with a RuntimeError[3]
>when using the Python 2 variant.
> 
> Which solution would be allowed for Stretch?

bootstrap-vz depends on python2-pyro4, so we can't just drop it.

I don't like 2, I'd rather add a new source than embed this inside pyro.

Please upload selectors34 and I'll see about granting an exception to fix this
RC bug.

Cheers,
Emilio

Bug#853770: unblock: pyro4

[Laszlo Boszormenyi (GCS)]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: unblock

Hi Release Team,

I don't want to hide that due to my mistake, pyro4 package migrated to
Stretch without the selectors34 dependency of python2-pyro4 even
packaged. It was only partly fixed with importing the selectors module
instead[1] - that fixes the client mode but the multiplexed server
still fails (the user have to change to the threadpool variant).

I see the following solutions:
1) Drop the python2 variant of Pyro4 and only ship the python3 one
   (worst case).
2) Allow the packaged selectors34 module[2] to Stretch (not yet
   uploaded) as it's an one file module.
3) Add the selectors34.py to the pyro4 package, debdiff to the Stretch
   version is attached.
4) Use the upstream commit not to fail with the import, but inform the
   user to switch to the threadpool variant with a RuntimeError[3]
   when using the Python 2 variant.

Which solution would be allowed for Stretch?

Thanks,
Laszlo/GCS
[1] https://bugs.debian.org/852245
[2] dget -x http://www.barcikacomp.hu/gcs/selectors34_1.1.0-1.dsc
[3] https://github.com/irmen/Pyro4/commit/edfdbb2ce4279d929b306d00ac8fb
c6543a0807bdiff -Nru pyro4-4.53/debian/changelog pyro4-4.53/debian/changelog
--- pyro4-4.53/debian/changelog	2017-01-06 12:45:50.0 +
+++ pyro4-4.53/debian/changelog	2017-01-31 16:56:26.0 +
@@ -1,3 +1,20 @@
+pyro4 (4.53-3) unstable; urgency=medium
+
+  * Add selectors34 to Python2 package for proper Python2 compatibility
+(closes: #852245).
+
+ -- Laszlo Boszormenyi (GCS)   Tue, 31 Jan 2017 16:56:26 +
+
+pyro4 (4.53-2) unstable; urgency=medium
+
+  * Rework Python version detection.
+  * Remove requires.txt from the installed files.
+
+  [ Marcin Kulisz  ]
+  * Fix Python2 compatibility (closes: #852245).
+
+ -- Laszlo Boszormenyi (GCS)   Mon, 23 Jan 2017 21:17:56 +
+
 pyro4 (4.53-1) unstable; urgency=low
 
   * New upstream release.
diff -Nru pyro4-4.53/debian/control pyro4-4.53/debian/control
--- pyro4-4.53/debian/control	2017-01-06 12:45:50.0 +
+++ pyro4-4.53/debian/control	2017-01-31 16:56:26.0 +
@@ -33,7 +33,7 @@
 
 Package: python2-pyro4
 Architecture: all
-Depends: python2-serpent (>= 1.16), ${misc:Depends}, ${python:Depends}
+Depends: python2-serpent (>= 1.16), python-six, ${misc:Depends}, ${python:Depends}
 Conflicts: python3-pyro4
 Replaces: python3-pyro4
 Suggests: pyro4-doc, pyro4
diff -Nru pyro4-4.53/debian/copyright pyro4-4.53/debian/copyright
--- pyro4-4.53/debian/copyright	2013-07-10 18:22:45.0 +
+++ pyro4-4.53/debian/copyright	2017-01-31 16:56:26.0 +
@@ -25,6 +25,54 @@
  OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
  SOFTWARE.
 
+Files: debian/selectors34.py
+Copyright: Copyright (C) 2015- Berker Peksag 
+License: PSFL-2
+ 1. This LICENSE AGREEMENT is between the Python Software Foundation
+ ("PSF"), and the Individual or Organization ("Licensee") accessing and
+ otherwise using this software ("Python") in source or binary form and
+ its associated documentation.
+ .
+ 2. Subject to the terms and conditions of this License Agreement, PSF hereby
+ grants Licensee a nonexclusive, royalty-free, world-wide license to reproduce,
+ analyze, test, perform and/or display publicly, prepare derivative works,
+ distribute, and otherwise use Python alone or in any derivative version,
+ provided, however, that PSF's License Agreement and PSF's notice of copyright,
+ i.e., "Copyright (c) 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009,
+ 2010, 2011 Python Software Foundation; All Rights Reserved" are retained in
+ Python alone or in any derivative version prepared by Licensee.
+ .
+ 3. In the event Licensee prepares a derivative work that is based on
+ or incorporates Python or any part thereof, and wants to make
+ the derivative work available to others as provided herein, then
+ Licensee hereby agrees to include in any such work a brief summary of
+ the changes made to Python.
+ .
+ 4. PSF is making Python available to Licensee on an "AS IS"
+ basis.  PSF MAKES NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR
+ IMPLIED.  BY WAY OF EXAMPLE, BUT NOT LIMITATION, PSF MAKES NO AND
+ DISCLAIMS ANY REPRESENTATION OR WARRANTY OF MERCHANTABILITY OR FITNESS
+ FOR ANY PARTICULAR PURPOSE OR THAT THE USE OF PYTHON WILL NOT
+ INFRINGE ANY THIRD PARTY RIGHTS.
+ .
+ 5. PSF SHALL NOT BE LIABLE TO LICENSEE OR ANY OTHER USERS OF PYTHON
+ FOR ANY INCIDENTAL, SPECIAL, OR CONSEQUENTIAL DAMAGES OR LOSS AS
+ A RESULT OF MODIFYING, DISTRIBUTING, OR OTHERWISE USING PYTHON,
+ OR ANY DERIVATIVE THEREOF, EVEN IF ADVISED OF THE POSSIBILITY THEREOF.
+ .
+ 6. This License Agreement will automatically terminate upon a material
+ breach of its terms and conditions.
+ .
+ 7. Nothing in this License Agreement shall be deemed to create any
+ relationship of agency, partnership, or joint