Bug#625509: python3-debian and python 3.3

Stuart Prescott stuart+debian at nanonanonano.net
Mon Jun 18 23:02:10 UTC 2012


Hi Colin,

apologies for not being more exact for you in the previous email -- hopefully 
this makes up for it!

> >     def seekable(self):
> >         return True
> 
> In arfile.ArMember, right?  

correct -- patch attached if that helps

> > the others look like a change in the way subprocess thinks about
> > communicate() but I can't see anything in the 3.3 release notes that
> > discusses this.
> 
> I think those other failures indicate that you're missing the
> python3-apt patch from #656288.  Could you make sure of that?  It'd be
> good to ensure that this all tests out cleanly with 3.3.

On double checking, I realise that I do not have python3-apt installed in that 
chroot and that python-debian is falling back to its internal parser. I should 
also reiterate that the test suite passed without issue with sid's python3 
(3.2.3~rc2-1) package; the test suite failures are all in the communication 
with gpg not apt. 

The root of all the failures is deb822.GpgInfo.from_sequence() and its 
interaction with subprocess. While the changes summary for 3.3 doesn't mention 
anything about subprocess, there's a 1000 line diff between 3.2.3 and 3.3.0a4. 
The key difference is that the "universal_newlines" behaviour flag now influences 
the data that is sent to stdin of the subprocess as well as the stdout/stderr 
coming back. This means that the input data given to subprocess.communicate() 
must be of the appropriate type:

	«The type of input must be bytes or, if universal_newlines was True, a 
string.»

http://docs.python.org/dev/library/subprocess.html#subprocess.Popen.communicate

My reading of this is that for python3.3, setting universal_newlines=True and 
sending bytes is wrong. The attached patch turns universal_newlines off and 
sends bytes in both directions. The alternative would be to leave 
universal_newlines=True and fix the treatment of "inp" before passing it to 
p.communicate(). I have no feeling either way other than the changes I made 
looked less invasive.

(BTW if GpgInfo._get_full_string() is going to return bytes, perhaps the 
method name and docstring should change -- misleading method names make bytes 
vs strings even harder to track down than they otherwise should be.)

Application of the two attached patches along with your patch stack allows the 
test suite to pass with both python3.2 and python3.3a4.

cheers
Stuart

-- 
Stuart Prescott    --    www.nanonanonano.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: armember-seekable.patch
Type: text/x-patch
Size: 416 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-python-debian-maint/attachments/20120619/651b8ea4/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: subprocess-encoding.patch
Type: text/x-patch
Size: 869 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-python-debian-maint/attachments/20120619/651b8ea4/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.alioth.debian.org/pipermail/pkg-python-debian-maint/attachments/20120619/651b8ea4/attachment.pgp>


More information about the pkg-python-debian-maint mailing list