Bug#938027: python-pip: Python2 removal in sid/bullseye

[Barry Warsaw]

Hi Sandro.

Honestly, I have not contributed to Debian in a couple of years, and I don’t 
see that changing any time soon.  Best to contact Matthias, the Python Team, or 
just do whatever you think is best.

Cheers,
-Barry

> On Mar 13, 2020, at 12:32, Sandro Tosi  wrote:
> 
> On Fri, 30 Aug 2019 07:44:13 + Matthias Klose  wrote:
>> Package: src:python-pip
>> Version: 18.1-5
>> Severity: normal
>> Tags: sid bullseye
>> User: debian-pyt...@lists.debian.org
>> Usertags: py2removal
> 
> the only rdeps of `bin:python-pip` have been removed from testing, so
> it's probably time we drop this package too!
> 
> Carl, Barry: do you see anything wrong with this? what should we do
> about the -whl package? is it still required for something or can we
> drop it along with bin:python-pip? is it needed for anything
> py3k-related?
> 
> I would like to proceed quickly, ideally within a week.
> 
> thanks,
> Sandro



signature.asc
Description: Message signed with OpenPGP

Bug#890621: forwarded python3.6 issue (bpo-32305 causing regressions)

[Barry Warsaw]

On Feb 19, 2018, at 04:08, Matthias Klose  wrote:
> 
> This is https://bugs.python.org/issue32305, apparently intentional and will be
> in 3.7.  So better fix the packages itself. Not sure if that really should be
> backported.

Thanks for the forward.  The fix is for third party packages to use 
`getattr(module, ‘__file__’, None)` instead of `hasattr(module, ‘__file__’)`.  
I think gunicorn has already fixed this in their upstream.



signature.asc
Description: Message signed with OpenPGP

Bug#799281: ITP: mailman3-core -- Mailing list management system

[Barry Warsaw]

On Sep 22, 2017, at 18:53, Pierre-Elliott Bécue  wrote:

> Now, when I run the tests, there are a lot of errors, but I can't say
> exactly why. If you wish I can put a copy of the last attempt.

Sure, post a link.  I’ll let you know if I see anything obvious.

-B



signature.asc
Description: Message signed with OpenPGP

Bug#799281: ITP: mailman3-core -- Mailing list management system

[Barry Warsaw]

On Sep 22, 2017, at 09:28, Pierre-Elliott Bécue  wrote:
>> 
>>> In d/tests/mailman3-core-tests, what do you think about using `python3 -m 
>>> nose2` instead of `nose2-3`?
>> 
>> As I wasn't able to have working tests for this package, they're disabled in
>> d/rules. Maybe I just should remove this file.

Can you remember why the test suite doesn’t work in d/rules?

I do think that if they can’t be run in d/rules, they should be run at some 
point, and autopkgtests are a good alternative.  While that doesn’t block 
promotion in Debian (yet?) it does in Ubuntu, so there should be good feedback 
when the autopkgtests fail.

That said, in my own packages I always try to include a few other autopkgtests. 
 Things like:

* Run the command line (e.g. ``mailman —help``)
* Try to create a simple list
* Do a simple ``mailman shell`` command
* Hit the REST API and just make sure it returns some non-error.

>> Another interesting integration test might be to start up MM3’s REST API and 
>> GET the /3.1/system/versions resource, then either print the JSON or compare 
>> its value to something expected.  It’s at least a minimal sniff test that 
>> some runners could be started up.
>> 
>> I think this requires more background on mailman3 functionnalities that I
>> currently have. Maybe I'll set this suggestion in debian/TODO for later!

+1!  Tests are an investment over time, so just get the bare minimum working 
now, and it can always be improved.

>> autopkgtest fails for me with:
>>> 
>>> After this operation, 159 MB of additional disk space will be used.
>>> Err:1 http://httpredir.debian.org/debian sid/main amd64 python3-falcon 
>>> amd64 1.0.0-2+b1
>>>  404  Not Found
>>> E: Failed to fetch 
>>> http://httpredir.debian.org/debian/pool/main/p/python-falcon/python3-falcon_1.0.0-2+b1_amd64.deb
>>>   404  Not Found
>>> E: Unable to fetch some archives, maybe run apt-get update or try with 
>>> --fix-missing?
>>> autopkgtest [20:07:28]: ERROR: testbed failure: apt repeatedly failed to 
>>> download packages
>> 
>> I guess I'm not able to do such test myself.

You should be able to build the source package, and then if you have a chroot, 
just do:

$ autopkgtest mailman-core-blah-blah.dsc — schroot sid-amd64

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP

Bug#799281: ITP: mailman3-core -- Mailing list management system

[Barry Warsaw]

Hi guys, apologies for not responding earlier.  I have taken a break from 
Debian development, so I am not reading my @debian.org email much these days:

https://lists.debian.org/debian-python/2017/08/msg00107.html

That said...

> On Sep 20, 2017, at 12:53, Jonas Meurer  wrote:

> @barry: I could do the uploads but as you're PEB's sponsor so far you
> might want to do that yourself. Maybe you also want to review the latest
> changes to the packages? That would be awesome.

Jonas, Mattia, thank you very much for working with PEB, and thanks to PEB for 
being so diligent about getting Mailman 3 into Debian!  I wholeheartedly 
support your sponsorship of these packages while I am on hiatus.

I did a quick review of the core package, and noticed just a few things:

d/copyright should really go back to 1998.  Even though Mailman 3 was forked 
from Mailman 2 only in the last few years, there’s enough code inherited from 
the early days to warrant the earlier copyright start year.

In d/tests/mailman3-core-tests, what do you think about using `python3 -m 
nose2` instead of `nose2-3`?

Another interesting integration test might be to start up MM3’s REST API and 
GET the /3.1/system/versions resource, then either print the JSON or compare 
its value to something expected.  It’s at least a minimal sniff test that some 
runners could be started up.

If and when you get a real manpage, please write it in reST, convertible via 
rst2man and contribute it back upstream!

autopkgtest fails for me with:

After this operation, 159 MB of additional disk space will be used.
Err:1 http://httpredir.debian.org/debian sid/main amd64 python3-falcon amd64 
1.0.0-2+b1
  404  Not Found
E: Failed to fetch 
http://httpredir.debian.org/debian/pool/main/p/python-falcon/python3-falcon_1.0.0-2+b1_amd64.deb
  404  Not Found
E: Unable to fetch some archives, maybe run apt-get update or try with 
--fix-missing?
autopkgtest [20:07:28]: ERROR: testbed failure: apt repeatedly failed to 
download packages

Didn’t try to debug that.  Building the package locally works and makes lintian 
happy.  Didn’t try to install it.

Everything else LGTM!


signature.asc
Description: Message signed with OpenPGP

Bug#641314: debhelper: dh_auto_test should support standard python cli for running tests

[Barry Warsaw]

Hi Niels,

> On Sep 17, 2017, at 09:31, Niels Thykier  wrote:
> Is there an update to the situation here?  Can we assume that the test
> target is (generally) always available ?  (even if we limit it to just
> python3 related calls).

No, I don’t have any update to this.  I am taking a break from Debian 
development (not retiring!) so don’t expect any progress on this in the near 
future.



signature.asc
Description: Message signed with OpenPGP

Bug#862072: [Python-modules-team] Bug#862072: python3-virtualenv doesn't provide entry point virtualenv

[Barry Warsaw]

On May 08, 2017, at 10:16 AM, Mickael Viey wrote:

>After a python3-virtualenv fresh install. The package is installed on
>/usr/lib/python3/dist-packages, but doesn't provide any entry point to invoke
>virtualenv:

That's correct.  python3-virtualenv is just the library.  Install the
`virtualenv` package to get the /usr/bin script.

% apt-file search /usr/bin/virtualenv
virtualenv: /usr/bin/virtualenv
virtualenv-clone: /usr/bin/virtualenv-clone

Bug#859421: python-tz orphaning

[Barry Warsaw]

On Apr 07, 2017, at 02:47 AM, Matthias Klose wrote:

>I think it's safe to go forward with this. Maybe keep the zope team (or the
>individual uploaders) as an uploader for a while, but I think the zope team
>is a little bit dead at this point ...

I really think we should pull the zope library packages into DPMT.

Bug#859747: pycxx 7.0.1-1 fails its autopkgtest

[Barry Warsaw]

Source: pycxx
Version: 7.0.1-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I just noticed this over in Ubuntu, where pycxx 7.0.1-1 is failing its
autopkgtest, which prevents it from getting promoted out of
zesty-proposed.  Retested on unstable, in a sid chroot, the exact same
failure occurs.

https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty/zesty/amd64/p/pycxx/20170329_091528_f4dc4@/log.gz

autopkgtest [15:13:29]: test buildtest: ---]
autopkgtest [15:13:29]: test buildtest:  - - - - - - - - - - results -
- - - - - - - - - -
buildtestFAIL non-zero exit status 1
autopkgtest [15:13:29]: test buildtest:  - - - - - - - - - - stderr -
- - - - - - - - - -
Traceback (most recent call last):
  File "test_example.py", line 40, in 
  import example
  ImportError:
/tmp/autopkgtest.BUHlO2/autopkgtest_tmp/examples/local/lib/python2.7/site-packages/CXX/example.so:
undefined symbol: _ZN2Py26ifPyErrorThrowCxxExceptionEv
autopkgtest [15:13:29]:  summary
buildtestFAIL non-zero exit status 1

I don't know if this ever worked.

- -- System Information:
Debian Release: 9.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhBcVftvnPZ6sHlObEm61Y6dLBr8FAljmlAoACgkQEm61Y6dL
Br/Y+Q/9GgkEMluf+ff18Bko3CdV3z1yGJ0r+l6H5xp43jZ+bUNFp5EPZI45JwFQ
2ZfTTnhXlrlGN/LBTvC/BRveJEAYYfzYLQqOniMnB/4nJhY1Y/o7fwK7519yC2oN
zRX6u6MwEcfzmJpGuCsk8qD016vQDe9UHwvhrZ2MCNo+tV6ws9+TQHmRgi3850XY
iiTWnOohiFMHKtBVLkHR08WLgitZZAv20Fi1Q2z0WmXIXQtSXQ5Q3iaBXoTUDzCM
tOwKqiZYqcdfsEK8MMew8Il6AYOG11SzO7EdOZR1412txo8IPocExdpJK5uq7pJf
dnBdovkhN+gtsIsHRZRyOQ1Wzel5mDkbM9iSX/LthxmW4gkad5rOX31k+i/AJOWN
b6oa31DEep9LH1Y+rnaV7rQH5c8Fvm3x3sR6DN+cphbXlUDsGmi4ctmFHOe6HtHk
oh7W71+vVTcVcGtaEDlbUJ7/CJp7AoOJYCbu9dyiv2nrXt4eCBeIqJi+Xqc0Lrtr
l2XzE+RWPkDLCtHuWxQHMfJyarvV8wL4C3PVxf+vxJ2M129y2qlMZWiaNzY/UpDh
Bubu+nKHDM2rLzyIqZYBqnOkWlVqJMprPFnfWwIH0A3UwKS0g5OfjNNx70LSNw3X
8ffAkle3j91vuS1bxrWUYU5VjHlBmimfiT9UQjpM/yZxULOKqEg=
=B/8Y
-END PGP SIGNATURE-

Bug#852289: [Python-modules-team] Bug#852289: python-passlib: please make the build reproducible (timestamps)

[Barry Warsaw]

On Jan 31, 2017, at 09:43 AM, Eli Collins wrote:

>Passlib 1.7.1 is out, which should fix #852289; I'll try to keep an eye on
>the reproducible build status for a bit in case there's any other hiccups.

Thanks!  I'm working on the new upstream in git right now.  It looks like we
can also drop the 0001-Disable-Django-support.patch since

https://bitbucket.org/ecollins/passlib/issues/68/tests-fail-with-django-19

is resolved upstream.  I'm not a Django expert though so please let me know if
this is not correct.

Cheers,
-Barry


pgpaSH_AHEkxO.pgp
Description: OpenPGP digital signature

Bug#812768: [Python-modules-team] Bug#812768: python-whoosh: diff for NMU version 2.7.0-1.1

[Barry Warsaw]

On Jan 30, 2017, at 08:21 AM, Simon McVittie wrote:

>Thanks for letting me know, I'll mark it as unmaintained. Would you like
>your other packages to be marked as unmaintained too?
>
>Sorry, I am not intending to adopt python-whoosh: I'm only fixing it
>because removing it from testing would be disruptive for other packages
>in Debian.

I'd be willing to help maintain whoosh, but only with DPMT as Maintainer and
myself as Uploader.

Given the ongoing discussion over in debian-python@ it might not be worth
git-dpm'ifying it, but instead just moving the vcs branch over to the team
repo.  If this is acceptable, let me know.

Bug#744741: (no subject)

[Barry Warsaw]

Maybe, create a python{,3}-pyside-common package that only contains the
.egg-info and then have all subpackages depend on that?

Bug#852475: autopkgtest: apt-get install needs automatic conffile handling

[Barry Warsaw]

Hi Martin,

On Jan 24, 2017, at 09:19 PM, Martin Pitt wrote:

>Ah, sbuild usually copies that from the host system
>(/etc/schroot/default/nssdatabases), so indeed this tends to cause conffile
>conflicts.

Ah ha!  That was the piece I was missing.

Thanks for applying the patch.

-Barry


pgp08bth0I0vq.pgp
Description: OpenPGP digital signature

Bug#852475: autopkgtest: apt-get install needs automatic conffile handling

[Barry Warsaw]

https://code.launchpad.net/~barry/autopkgtest/+git/autopkgtest/+ref/852475


pgp9syopDe3sn.pgp
Description: OpenPGP digital signature

Bug#852475: autopkgtest: apt-get install needs automatic conffile handling

[Barry Warsaw]

Package: autopkgtest
Version: 4.3
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear Maintainer,

Let's say one of your autopkgtest dependencies (perhaps recursively)
needs to update a configuration file, i.e. via a conffile.  E.g. when
running the autopkgtests for aptdaemon in an Ubuntu Zesty chroot, the
netbase package wants to be installed, and this has conffiles for
/etc/{protocols,rpc,services}.

This can break the tests when dpkg needs to query about updating these
conffiles because the default is to --force-confdef, which prompts the
user and waits for a response.  This fails in the following way:

Setting up netbase (5.4) ...

Configuration file '/etc/protocols'
 ==> File on system created by you or by a script.
 ==> File also in package provided by package maintainer.
   What would you like to do about it ?  Your options are:
Y or I  : install the package maintainer's version
N or O  : keep your currently-installed version
D   : show the differences between the versions
Z   : start a shell to examine the situation
 The default action is to keep your current version.
*** protocols (Y/I/N/O/D/Z) [default=N] ? dpkg: error processing package 
netbase (--configure):
 end of file on stdin at conffile prompt
 
Thus the test dependencies can't be installed and the entire
autopkgtest fails.

It would be better I think when setting up the testbed, to pass to the 
`apt-get install` command an additional option: 
- -o Dpkg::Options::="--force-confnew" so that the prompt is bypassed
and the dependency can be installed.

I can't think of a reason why you'd want to retain the old conffile,
since the testbed is (usually? always?) ephemeral.  If you can think
of a use case for that, then an autopkgtest option would probably be
required.  I'd opt for YAGNI and just include that dpkg option
unconditionally.  

Seems like it should be a relatively easy fix in adt_testbed.py; I'll
try to put together a branch and test it.

- -- System Information:
Debian Release: 9.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages autopkgtest depends on:
ii  apt-utils   1.4~beta4
ii  libdpkg-perl1.18.18
ii  procps  2:3.3.12-3
ii  python3 3.5.3-1
ii  python3-debian  0.1.29

Versions of packages autopkgtest recommends:
ii  autodep8  0.8

Versions of packages autopkgtest suggests:
pn  lxc  
pn  lxd-client   
pn  qemu-system  
pn  qemu-utils   
ii  schroot  1.6.10-3

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhBcVftvnPZ6sHlObEm61Y6dLBr8FAliHr7kACgkQEm61Y6dL
Br9yew/+NRKoZ1e5B3z2I0MRdo2qiNOF76zaP6WDAAoFeLyQaplFshvIMmKTzvKt
cERFGnijEKWfeCPOP3wyLbotqVXHYqqJmiqDDmx7jFUJEUFYO9UIPqymUz6LGU4S
//Ya1GSYucOCw/VQQfHt1hAlsnyAxWfv2e87xfgFIDhxQihoQu7VZqA8dvGIkvRt
nbXiAPf4a2s9/MRjLctEAfwwyw3HbGSzytaDyCgiZH+r562tqccClfe7VhMfGn3j
QQvzumjELwcXPQbijZAiNeMHN4JEWQzzXwbRwndlq51F+tsCzrjPrm5bcUnILiVL
jA7mrZGMAHanOPl6F4ZC5Idfby7h6gXRqZ5Nc2o/+rUU+TX6iBb/TEtT64ejiy9O
G5PxrQGuL2WxEk8ObcVi6E5PW/L9hmx/T/kLm3oVdOEFEmxhPS95uNlu7aKnOg9N
6X4BeDej7UNwRVjG45lgKw1xW0xfZ5rLBvdQtQqsXkECZDgquW298eBM1D4JuPbc
I5bZyj4w7pNkWIrBglkeX6rxy3YzH+k/21Fx/pYAtG4PRfk09p7k+YOePATRrclf
FBOnf9+KzgfDiCTqgXB1HN/nxbpcTBirg0d4CCrdpW4wcru5VEpnEe9GRxJbY/X3
pZPKAoKkE4jTYgXICqaheEHjAtsh3k0rFNuYmLL9dUHnVi9zGI8=
=rNub
-END PGP SIGNATURE-

Bug#852289: [Python-modules-team] Bug#852289: python-passlib: please make the build reproducible (timestamps)

[Barry Warsaw]

On Jan 23, 2017, at 04:40 PM, Eli Collins wrote:

>In case this helps the debian package maintainer decide on this patch /
>schedule things, the timestamp problem this addresses is due to a bug in
>the passlib 1.7.0 setup script, which should be fixed in the 1.7.1 upstream
>release (due out next weekend).

Thanks for the status Eli.  If the bug is fixed upstream, I think it makes
sense to just wait until 1.7.1.  Feel free to drop us a ping when that's
available (though I'll eventually notice it anyway).  If Brian doesn't beat me
to it, I'm happy to update to 1.7.1 once it's available.

Bug#851649: (no subject)

[Barry Warsaw]

I have no objections, but I don't have time right now to do it.  Piotr did the
1.7.0-1 upload so please verify with him.

Bug#844943: python-bleach: FTBFS: Tests failures

[Barry Warsaw]

On Jan 13, 2017, at 09:16 PM, Pirate Praveen wrote:

>I would prefer this approach as I prefer to avoid maintaining two
>versions if possible. I cloned html5lib.git repo, but found recent tags
>missing there. Can you push them?

Apologies.  Tags pushed.  Let me know when you have a repo or branch for me to
test and I will do QA on pip and friends.


pgpBaMg2Bcian.pgp
Description: OpenPGP digital signature

Bug#844943: python-bleach: FTBFS: Tests failures

[Barry Warsaw]

Here's another thought.

What if we upload a new html5lib source package containing seven-9's?  I know
we're in freeze, but this may make the most sense.  Then, packages which need
the old version like bleach can depend on the seven-9's version and that won't
affect packages which require the newer version like pip.

Eventually bleach will fix their package to work with the newer html5lib, or
even html5lib 1.0 when that gets released.  Then we can remove the seven-9's
package.  It's something of a mini-transition, and I'm not happy about having
to do that, but it seems to be the least painful suggestion for now, with the
least possibility of regressions or breakages.

Cheers,
-Barry



pgpoIISfZz1IH.pgp
Description: OpenPGP digital signature

Bug#783202: (no subject)

[Barry Warsaw]

I've run into this --or something similar-- too.

$ autopkgtest-buildvm-ubuntu-cloud -v

When you run this on an Ubuntu 17.04 (zesty) host, it finishes quickly and
leaves you with a nice autopkgtest-zesty-amd64.img.  When you run the same
command on an Ubuntu 16.10 (yakkety) host, it hangs and eventually times out.

I've seen it hang in different spots, so I'm not sure what's going on, but
usually when it times out, it does indicate a timeout in cloud-init.  E.g.

[   60.843487] cloud-init[1416]: Found kernel: /boot/vmlinuz-4.9.0-11-generic

--> hangs here for a long time, but eventually returns

 Starting Cleanup of Temporary Directories...
[  OK  ] Started Cleanup of Temporary Directories.

--> hangs here for a long time

timed out on cloud-init
qemu-system-x86_64: terminating on signal 15 from pid 6948

Bug#844943: python-bleach: FTBFS: Tests failures

[Barry Warsaw]

On Jan 10, 2017, at 09:37 AM, Pirate Praveen wrote:

>bleach and other projects using html5lib seems to have locked the version of
>html5lib to the one with 7 nines. Can we also go back to the older version
>which works?

I had a conversation with the upstream pip maintainer.  In theory it may be
possible.  In practice it's often a nightmare to go backwards.  I'm willing to
help try to make that happen if others are also willing to help.

>It is not sustainable to expect maintainers to reverse dependencies to fix
>breakage with out giving them advance notice. Since python-bleach has
>autopkgtests defined, it would have been easy to find out if an update of
>python-html5lib would break it or not using a tool like build-and-upload
>script from pkg-ruby-extras team [1]

I'm not sure why you think I'd know anything about an obscure Ruby tool.  I
still contend that Debian ought to have automatic promotion gating on reverse
dependency building and testing.

All that aside, if someone wants to help put together a git branch that
properly reverts html5lib to seven-9's, I will gladly review and test it with
pip, and upload it if it looks okay.

Cheers,
-Barry


pgpFj0CJk4Gu5.pgp
Description: OpenPGP digital signature

Bug#769598: (no subject)

[Barry Warsaw]

Okay, I figured out the problem and have a fix.  I don't believe this is a bug
with dput-ng (so this issue can be closed), but instead it's a problem with
the local user's trustdb.  You'll have to fix your trustdb locally and then it
should work.  Here are a couple of links with some additional clues:

https://github.com/keybase/keybase-issues/issues/821
http://stuff-things.net/2015/04/22/gpg-public-key-of-ultimately-trusted-key--not-found/

Bug#769598: (no subject)

[Barry Warsaw]

I'm hitting this same problem.  I thought maybe it was related to having a
$GNUPGHOME set, but even unsetting that doesn't help.  It fails every time
using either a name or uid (full or short).

Bug#835437: Seems fixed

[Barry Warsaw]

On Dec 25, 2016, at 05:49 PM, Santiago Vila wrote:

>The bug I reported said FTBFS. After the tests are disabled, this builds
>ok again, so the FTBFS problem I reported is fixed.

Thanks.  If you're happy closing this bug, then so am I!  I'll just clarify
that I didn't actually disable the tests; they were already disabled, in the
sense that the exit code of the failing build-time tests were already
explicitly ignored in the d/rules target.

>Well, I would like, but after building version 7.43.0-2 one hundred
>times the locale problem does not happen anymore.

Cool.


pgpTOFI8wHHG4.pgp
Description: OpenPGP digital signature

Bug#844457: [buildd-tools-devel] Bug#844457: sbuild: --extra-package is great, but could be better

[Barry Warsaw]

On Dec 22, 2016, at 08:50 AM, Johannes Schauer wrote:

>If the path given to --extra-package is a directory, then sbuild will add all
>files that end in ".deb" within that directory to its local repository.
>
>Does that sound like a good compromise to you?

It does indeed, thanks!
-Barry


pgpyPVZk_tC_P.pgp
Description: OpenPGP digital signature

Bug#838695: (no subject)

[Barry Warsaw]

We just hit this same problem.  I think this is exactly the right fix.  I
tested it locally in a venv.  Unfortunately I don't have permission to push
the fix to the repo.

Also, PyPI is a version behind unstable.

Bug#840673: (no subject)

[Barry Warsaw]

On Dec 15, 2016, at 05:39 PM, Matthias Klose wrote:

>disagreed, dput should just remove setuptools from the requires.

I agree that the bug should be fixed in dput.  It's up to dput's maintainer to
decide how I suppose.  Sounds like there's agreement we should reassign this
bug back to dput.



pgpBuPxzBvHya.pgp
Description: OpenPGP digital signature

Bug#835437: (no subject)

[Barry Warsaw]

I can't reproduce the build failures reported here even with dpkg-buildpackage
-A.  However, I am going to add the discard-port proxies to d/rules that
pybuild normally adds by default (this package doesn't use pybuild).  That at
least will prevent the tests from *actually* hitting the internet.  I'll close
#830281 against that change.

Yes, this makes the test suite fail during package build.  I have reported
this upstream at https://github.com/pycurl/pycurl/issues/424

However note that d/rules currently discards test suite errors, so they don't
prevent the build from succeeding.  This makes running the tests semi-useless
but I think until upstream fixes their test suite, it's the best we can do.
Therefore I'm going to tag this bug as unreproducible and reduce the
severity.

I also can't reproduce the C locale problem, but I'm going to consider that a
separate bug so please file a new one on that issue.

Bug#840673: (no subject)

[Barry Warsaw]

I think one of the problems is that while in Debian, pkg_resources and
setuptools are separate binary packages, it's not entirely clear to me that
upstream views them as different packages.  After all, they are Python
packages distributed in the same git repo and tarball.  Debian's separation of
them is a bit artificial.

You could solve this by promoting *-pkg-resources Suggests of *-setuptools to
a Depends, but that sets up a circular package dependency since *-setuptools
Depend on *-pkg-resources.  In a sense I think that reflects the bootstrapping
issues raised by upstream in GH#863.

Does it ever make sense to install pkg_resources and not install setuptools?
I'm not so sure, but collapsing them at this point is probably more intrusive
than what we want.  Another option would be to create new meta packages which
Depend on both *-pkg_resources and *-setuptools and encourage people to Depend
on that.

Ultimately for this specific case, I think it's just easier if dput added a
Depends on python-setuptools.

Bug#839253: (no subject)

[Barry Warsaw]

A couple of small decisions in discussion w/Martin:

* If you have `Tests: foo` and `Features: test-name=bar`, warn and ignore the
  test-name feature.

* If you have multiple test-name features, e.g.
  `Features: test-name=a, test-name=b`
  warn and skip.

* I want the feature name to match the command line option, but inconsistent
  with the other autopkgtest options, we have --testname.  For consistency,
  this should be called --test-name, so let's support --test-name as an alias
  and deprecate --testname, with eventual hiding and/or removal some time
  later.

Bug#846328: RFH: autopkgtest -- automatic as-installed testing for Debian packages

[Barry Warsaw]

On Nov 30, 2016, at 11:48 AM, Martin Pitt wrote:

>but I'd really like to mentor other people about the structure, how to test
>autopkgtest itself locally, etc.

I'd like to get more involved with auutopkgtest, since it's a tool I rely on
quite a bit.

Cheers,
-Barry

Bug#837764: (no subject)

[Barry Warsaw]

Are you sure that link actually exists?

Bug#846155: ITP: python-distro -- Linux OS platform information API

[Barry Warsaw]

Package: wnpp
Severity: wishlist
Owner: Barry Warsaw <ba...@debian.org>

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: python-distro
  Version : 1.0.1
  Upstream Author : Nir Cohen
* URL : https://github.com/nir0s/distro
* License : ASLv2
  Programming Lang: Python
  Description : Linux OS platform information API

distro (for: Linux Distribution) provides information about the Linux
distribution it runs on, such as a reliable machine-readable ID, or
version information.

It is a renewed alternative implementation for Python's original
platform.linux_distribution function, but it also provides much more
functionality which isn't necessarily Python bound like a command-line
interface.

This package is a new dependency for pip 9.0.1.  I will maintain this
package within the Debian Python Modules Team.

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhBcVftvnPZ6sHlObEm61Y6dLBr8FAlg8hjAACgkQEm61Y6dL
Br9yiQ//eIBSrjI1H4H4WDcJknCJJF8Xv1OHsKqP9Kz3MDTtSgDItl/hyOzxeebs
LNhiTQGe4rdrZsUFfPdcw4XPzSjsqBR5GYifEIIwzextaVwkyDNryKnM8ICeuV7B
XKrLeXnc6GkPq61kf79XoJLOfTAnnbhHQQHakZhTAI4JnNSpnpi98xburu+Y3YtY
eY2gVQAgfrGbwmEE3twWJh8MW0357D7LY6TnOS0mB1b09qBsNzIkDCUwsfm1zRg5
EKb39w2PUjRQVpuKWXdU96GBSMoCTMIMcOtQ9qjNlOBQ8MjWvvY1t1EKDGa/MeP1
uBPYxyZ6nxfceWf6GvL3/NIa8Gz/YdcJMJtkO1Xe3xQnP/SGOMd3PSTJ5YI4EFWR
VLiQThczYKZ8U1l6yyWpR9GmojGpgslI9Pm6X0E50dM/cLvDR0mRGvxB4FUC1ie6
LZiKiHOWQ/Ta7D2TaBpTlYr418viy+lbsfZiixkzD7RVQD9gcarz3kdmbgzb/Pcq
Uy9F6zYdt9X2vNgicE2SxpzGYcDTKqQ3nOg/Uic9Vxc4n5Hrzbz84o0Rb9CQzBGs
QBniwko/EzPTcTWGtWI/V0OyJztcbBqa5qWeZx9QjgZIsoyk7MpOUFSnP4jCvqEF
e6cERQmHnIonzDjoYfLil9siKvoDYVgtQx0t1s+kyWZnKN6fcd0=
=bPTT
-END PGP SIGNATURE-

Bug#844679: [Python-modules-team] Bug#844679: /usr/bin/pip: Should use --disable-pip-version-check by default

[Barry Warsaw]

On Nov 17, 2016, at 11:17 PM, Nelson A. de Oliveira wrote:

>Since we are installing pip from a Debian package, shouldn't we have it
>using "--disable-pip-version-check" by default, to avoid this?

Yes, I think we should.

Bug#844650: ITP: flufl.testing -- a small collection of Python test helpers

[Barry Warsaw]

Package: wnpp
Severity: wishlist
Owner: Barry Warsaw <ba...@debian.org>

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: flufl.testing
  Version : 0.1
  Upstream Author : Barry Warsaw <ba...@python.org>
* URL : https://gitlab.com/warsaw/flufl.testing
* License : ASLv2
  Programming Lang: Python
  Description : a small collection of Python test helpers

This package includes plugins for the following test tools: nose2,
flake8.  The plugins provide useful features (e.g. filtering tests
based on a regular expression) and ensure some common coding styles
(e.g. import order).  They can be enabled independently.

This package refactors code in the test suites of several other
packages and will be used to eliminate the usual skew due to cargo
culting.

I will package this as part of the DMPT.

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhBcVftvnPZ6sHlObEm61Y6dLBr8FAlguB4AACgkQEm61Y6dL
Br/G6w/+Nb2Rxl/TsLMIHRSNjOA1wTx0OVgR+PUygn4g8M2kOzp+XxmlUwiuqcF5
VfcV55EKmq03gKEvLe+OIa/dTgwfg/tEhVaV1rw8i3PY0QETUDejeiInyVMqttgQ
D5oAGAWp/9CrgYfk2AXvI/9txBbVQJzwVCKGDTk+B9RFgnGMYcESFcwSbTatQ0xB
P6LQTmMCWPnWgkBQBjYmCDm68pLmlYKW4UcrXpjRdfuqMZCI5KtRr+Ulddg1gCfW
Oq+o8MTST7Xu4/UYaIzdWlwXo44c8UKa81XPwSYjkEaiedX6JPzqGG3vLU6zoPNA
HH2EA+sd4/vYuP/HaJrb37yTnXWlZ5JI1J9FfjO+j5J3ihPLLkQxhFLH3P+qg/Ue
ce68gIE0qxqodLbEu+ceEm7B3gn56qJXaKyI3GLMIltnx899BNk5d5GkTYhStijX
+HxxsM3vLY6pru3Tu/sdIeNcMX/Q8vRymr8VDV2ixcSLhfuF5kFrcUyyzcAdv1BP
yKvbcXmcqqnFurwoWKLWaMNe1A0wYXiMVmQOlPHBvVhC6PEALpgZENqiygNqMfk8
pC61SyMhBojcLR5nqVdOokUrP6BkORUM/j4POOLmqUkbPjM8X7iTukm7R7AnyAC7
kioL5t3ESCzjfi5+uUkJqDHv4C+q1GiCFUBiNsNeUnOXnopt9Kk=
=knJq
-END PGP SIGNATURE-

Bug#844561: claws-mail-python-plugin: Missing dependency on python-gtk2

[Barry Warsaw]

Package: claws-mail-python-plugin
Version: 3.14.1-1
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear Maintainer,

I was debugging a failure of the Claws Mail Python plugin on Ubuntu
17.04.  See LP: #1640217

https://bugs.launchpad.net/ubuntu/+source/claws-mail/+bug/1640217

What I found out through gdb tracing the loading of the plugin is that
it tries to "import gtk", which means it imports that package's
__init__.py.  However by default, claws-mail-python-plugin doesn't
depend on python-gtk2 (which is the package that owns that file), so
the import fails, and thus the loading of the plugin fails.

Given the reverse-depends on python-gtk2, I might not be normally
obvious that the dependency is missing, but it may not already be
installed on a fresh or minimal installation.

- -- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.8.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhBcVftvnPZ6sHlObEm61Y6dLBr8FAlgs060ACgkQEm61Y6dL
Br/kzQ//URKh0ioNTc7TvgQ1fvjR3FKHkbDHmCCzk9V89qQZrdyHfYK81hRwX2Qx
WyCn0Nv/u1ow/YQt2zCZgKpeaoFCA5i0AwfpKbzeM8Njp69AGdsHKePZk0hqSwf2
Ih63STMoHcE9xexi8zhQPnyXgnoPK9T9z0IRJ25qVBwDAK8pSWCJtfhu6whN7Zev
XchqmTQJuuupaDRzb9LLtLuReO26xJwav4PB4qYhA1EJG0IZlaFr7fTZGAwxDUe9
ODIn+t3hFprMMLBxOw4i19ftvAyIWt3DMnJ3tDb0eN7SZVkobxoZdPltN8Sgnv22
dzAdob9Wua2f2sgV8XodYsE7oOVb4wRT8t4TNgavppaPSGsQg/Foh6y1TTBjVhYk
dBfw9iSo6Ui0iTxT/rwYbX7Mcgl4q8sv5e5zu1Q14rifnJs5K8uOqS2oMKOzXkki
8/vkNi2nZk1m1pmRMe3XQNYT7keQ5R/ufJh7BWXhkHWh6m/fWLwAzISxAN1AhqtE
jtKHAwSiRkh56ioElLW5eto6GKLCvKoux1VAISlgtdhuKySYcx9+D64l2/ecOQU5
a4WZ6tDcG01puVdwUKU/SovtXMKlJv9CWTUjFTrW5YAyt6f86jwZZrYlXcdiKkyg
d/4HDq7YJmeeW5poWsb0prbZa4whHie6JfMPAaiKzIXBHG9Txhs=
=a/V1
-END PGP SIGNATURE-

Bug#844457: [buildd-tools-devel] Bug#844457: sbuild: --extra-package is great, but could be better

[Barry Warsaw]

On Nov 16, 2016, at 07:48 AM, Johannes Schauer wrote:

>> 1) Allow for passing wildcards to --extra-package.  Then I could do
>> something like `sbuild ... --extra-package=/path/to/itp/*.deb` and
>> have it pick up all the debs in that directory.
>> 
>> 2) Provide a shortcut option for --extra-package.  
>
>it seems that what you want is not to pass individual .deb files but a
>repository of them. Why not just put all your .deb into a directory, call
>"apt-ftparchive release" to create a Release file, start a http server inside
>that directory with "python3 -m http.server 8000 --bind 127.0.0.1" and then
>use:
>
>sbuild --extra-repository="deb [trusted=yes] http://127.0.0.1:8000 ./"
>
>This sounds like much but since you explained that you are doing this very
>often you could:
>
> - put the --extra-repository into your ~/.sbuildrc using $extra_repositories
> - configure a webserver to always serve from your chose directory locally (if
>   you don't like the idea to have yet another service running in the
>   background, you could even use an inetd based http server)
> - regenerate your archive using a simple inotify watcher on your chosen
>   directory
>
>Then, whenever you have a new .deb, you'd just throw it into that directory
>and when you call "sbuild" (without arguments) it would pick up everything
>you need.
>
>Would that not be superior to complicating the sbuild command line?

It's certainly possible, and I used to do some very similar things, but when
my old approach broke, I started to investigate what sbuild could do natively.
--extra-package is a nice feature, but then my first inclination was to try
using a wildcard in the path instead of a hardcoded single file.  When that
failed, I thought I'd request this simple enhancement.  It's not really a CLI
API change per se since you don't really need to add a new command line
switch, just do the globbing in sbuild.

I totally understand if you don't want to do it though.

Thanks for listening!


pgp329HljjINO.pgp
Description: OpenPGP digital signature

Bug#844455: autopkgtest: Please support additional (local) packages

[Barry Warsaw]

On Nov 16, 2016, at 08:43 AM, Martin Pitt wrote:

>As for building *in* autopkgtest with extra binaries, this doesn't
>currently happen indeed; local binaries are only added as an apt
>source for the test, but I think it would not hurt to supply them as
>build dependencies too.
>
>However, there is another difficulty: autopkgtest currently assumes
>--no-built-binaries as soon as you specify any deb on the command
>line, as that's usually what you want. For this corner case (build
>given source package but use locally built build dependencies) it
>would actually need to grow a --built-binaries flag again.

Yes, that's exactly what I'm looking for.  Thanks!


pgpFZcCf01kBL.pgp
Description: OpenPGP digital signature

Bug#844457: sbuild: --extra-package is great, but could be better

[Barry Warsaw]

Package: sbuild
Version: 0.72.0-2
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear Maintainer,

I use --extra-package to build new versions of packages that grow new
dependencies not yet in Debian.  While waiting for the latter to clear
NEW (or before the ITP-fixing upload), I can use --extra-package on
the dependency to ensure that it builds correctly.

That's great, but --extra-package is rather inconvenient because if I
have to depend on multiple .debs, I need to type out a bunch of
- --extra-package options.  E.g. to add both python-foo and python3-foo.

I have two suggestions to make this a little nicer.

1) Allow for passing wildcards to --extra-package.  Then I could do
something like `sbuild ... --extra-package=/path/to/itp/*.deb` and
have it pick up all the debs in that directory.

2) Provide a shortcut option for --extra-package.

Thanks!


- -- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.8.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages sbuild depends on:
ii  adduser 3.115
ii  apt-utils   1.3.1
ii  libsbuild-perl  0.72.0-2
pn  perl:any

Versions of packages sbuild recommends:
ii  debootstrap  1.0.86

Versions of packages sbuild suggests:
ii  autopkgtest  4.2
pn  deborphan
ii  wget 1.18-4

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhBcVftvnPZ6sHlObEm61Y6dLBr8FAlgrlHIACgkQEm61Y6dL
Br8xwg/+ITh7YkjkCepO3BIccxeCzym2+zWzhJk2jXTu2hQEV7FBObRj91SnAGBE
VuOmr+XXVs6jXuA6QzkN9GDyM2HaGIx14SM/a6wTi/m5KW20ETaP0wftbTVyOPtN
mE35H+5y+qAD4jF4AS6QxbF87dEqKcdZbXqAhddNzF+zsD9bfXs8wkfZ5dA1YJKr
ASJVtoKh8KtC29gcNo5i2ReA/ma3zEClc3aSTt6KemzFmq1HckFPo9w2ZTOn3kSU
q5cUpNHLzuDfw6NhulQo19p5+oCXRlb8Qamru3CcINZgPXi3TxYbImZybEnYg6Ha
Pdd04h/VzJUsUZGumuEdWD7hbUqg3oCaGSTCe9quo0BJk77er5HRPjoRm/CA4k6Z
Wb8TuIs3qckJT4g5NPPx18ymUxhVWESVHbu+3es4kd7k5WjyJJc8mxEwvJF/qqBY
Fv7IdUQoObgBIFrmdmR6RzV59qWumxFmKE8yoDJ7LGm8jhb6PsHmc1I1lyedHe62
DXkLZL9ReqgCjtky2bLHzr8Le8vrQ5hqworPzssK9doqG+ppqePsnoKu7fxYCUeW
t21eRIVG9iNfoSyOE2MtrokOApEq5F8XBH5kxB/e7QiEjOAagTgtgAuUDEmzmSu+
1Qlzh7a+co1h7+XiKAhvfJnDItP7U/XOiHL2xYfEflVGJ4ZCNjg=
=9rc2
-END PGP SIGNATURE-

Bug#844455: autopkgtest: Please support additional (local) packages

[Barry Warsaw]

Package: autopkgtest
Version: 4.2
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear Maintainer,

Occassionally I'm testing a new package version that has new
dependencies which aren't yet in Debian.  I can build the ITP'd
packages locally and build the new package version with e.g. sbuild's
- --extra-package arguments.  Although it's moderately inconvenient to
add a bunch of debs, it does work.

But I don't know that autopkgtest has a similar feature.  It would
need to build the new package with the extra debs and run the tests
after installing the extra debs.

- -- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.8.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages autopkgtest depends on:
ii  apt-utils   1.3.1
ii  libdpkg-perl1.18.14
ii  procps  2:3.3.12-2
ii  python3 3.5.1-4
ii  python3-debian  0.1.29

Versions of packages autopkgtest recommends:
ii  autodep8  0.8

Versions of packages autopkgtest suggests:
pn  lxc  
pn  lxd-client   
pn  qemu-system  
pn  qemu-utils   
ii  schroot  1.6.10-2+b2

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhBcVftvnPZ6sHlObEm61Y6dLBr8FAlgrkWEACgkQEm61Y6dL
Br98Ig/9ELcitiz/bM+nvqFmPf4CCLXZ+Khg2tWFHCyQbZxPGkvPQ4kIc0AHpRxV
roKDSPzuaoc6nrF81vHTMpLcY5n7X+2SpQUSUaPbZ3Y4whvIxW0ixHdCCqCblOZ1
iyRaZr3EgDe53CXl2EA1uepMIYkhc7mDb9FH6QgW108RXRN48Alv7PEvKtCnWYi4
Dbb2BQG7S4T82itAkmBrPiAM2yhFLFKrvFDxRaNfNaLv72D75pPbcmqP4RiwGmMO
AvSeaAnjBMfmu6riJgidZc2A31rHrYy1gK6UkI7WDWJiJN6QF8ESzXix04npIHHN
kq+RhJ7RL/Y4WVzSvn1HU+dyZYQpJ/54K+m3bCgS91AaR4dcTFaWEux2RXtqWRos
6PjXap/Wv4r57cE5g97ZIpyoFiYs99o4hGS1UyGLxZGlKAf1zHBW6F2+9/SiRWry
Yc0s8x6GE8JLozE9+nHeSzy/OYBrIn0fPEJTYNAUCnjTzPwXZZe+Jzw8tCf6oTH4
jnpkCfTemCQDc1shIA7+DoX4hdJjh3Laf37FEV/2Lgn0KcDfuQOyS2fJS7GgTdgX
9euVNex6iI/CzSCe4re7sOJxZ5kSldUmFX9HyRAnwzXibo8JBYxhoHBCx85atIGI
5UZOMby7m2E5Rcs45Kc+C18HVQnnC8Nq7XYrR+9lKPBPwnwPg0s=
=kTUe
-END PGP SIGNATURE-

Bug#754248: [Python-modules-team] Bug#754248: python-virtualenv: Error when attempting to create a python2.6 virtualenv

[Barry Warsaw]

On Nov 13, 2016, at 10:14 PM, Arthur de Jong wrote:

>I just ran into this today and I can confirm that the above fix allows
>me to move forward with a Python 2.6 virtualenv. Can you fix this for
>unstable?

Yes, I'll upload this fix to unstable momentarily.


pgp3LVKV9oZPC.pgp
Description: OpenPGP digital signature

Bug#835437: pycurl: FTBFS too much often (failing tests)

[Barry Warsaw]

On Nov 03, 2016, at 08:32 PM, Santiago Vila wrote:

>My recommendation: Please find the way to disable any tests which
>perform network access, I have the strong feeling that the build would
>never hang if those tests are disabled.

+1 - unfortunately I just don't have any spare cycles right now.  If someone
wants to work on this, I will gladly review, sponsor, or otherwise help get
your contribution landed.


pgpMYX3s0cmxX.pgp
Description: OpenPGP digital signature

Bug#835437: pycurl: FTBFS too much often (failing tests)

[Barry Warsaw]

On Nov 03, 2016, at 02:03 PM, Sandro Tosi wrote:

>Hey Barry, did you have a chance to look at this? might be also just
>forward it upstream and see how that goes. Thanks!

I'm sorry, I haven't. :(


pgp4tL3nYiOn2.pgp
Description: OpenPGP digital signature

Bug#777144: (no subject)

[Barry Warsaw]

Hi.  I'm not sure that's a reasonable thing to support, especially now that
stretch is the next version.  So much has changed in pip in the meantime, that
I think it will be too difficult to backport or otherwise make unstable's pip
work in any older versions.

Sorry for not getting to this bug in such a long time.  Please let me know if
it's obsolete and can be closed.

Bug#834193: Your mail

[Barry Warsaw]

On Mon, 31 Oct 2016 18:25:16 -0400 Barry Warsaw <ba...@debian.org> wrote:
> Thanks for the bug report.  I plan on fixing this in 8.1.2-3 but I think the
> shebang should be /usr/bin/python2 for /usr/bin/pip2.  Can you think of a
> reason not to do this?

Well, one reason is that it makes lintian unhappy:

E: python-pip: python-script-but-no-python-dep usr/bin/pip2

I think lintian is wrong, but in the meantime, I'll drop back to #!
/usr/bin/python.

Bug#834193: (no subject)

[Barry Warsaw]

Thanks for the bug report.  I plan on fixing this in 8.1.2-3 but I think the
shebang should be /usr/bin/python2 for /usr/bin/pip2.  Can you think of a
reason not to do this?

Bug#842738: ITP: python-webencodings -- Python implementation of the WHATWG Encoding standard

[Barry Warsaw]

Package: wnpp
Severity: wishlist
Owner: Barry Warsaw <ba...@debian.org>

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: python-webencodings
  Version : 0.5
  Upstream Author : Simon Sapin
* URL : https://github.com/gsnedders/python-webencodings
* License : BSD
  Programming Lang: Python
  Description : Python implementation of the WHATWG Encoding standard

In order to be compatible with legacy web content when interpreting
something like Content-Type: text/html; charset=latin1, tools need to
use a particular set of aliases for encoding labels as well as some
overriding rules. For example, US-ASCII and iso-8859-1 on the web are
actually aliases for windows-1252, and an UTF-8 or UTF-16 BOM takes
precedence over any other encoding declaration. The Encoding standard
defines all such details so that implementations do not have to
reverse-engineer each other.

This module has encoding labels and BOM detection, but the actual
implementation for encoders and decoders is Python’s.

This package is a new dependency for html5lib, which in turn is a
dependency for python-pip, so it will need to be rewheeled.

I intend to package this as part of the DPMT.

-BEGIN PGP SIGNATURE-

iQIcBAEBCAAGBQJYF6icAAoJEBJutWOnSwa/HggP/2V7UXMmQJg7l7cMeDH4rnOV
8cAGsYB2bAw+U8ShyI4Q27S+NfNm9Xa57voi0lv1pA1/SUn3Ragl6+NWr0XYrhBN
2oSm2myN5GWUZSCyAWAxletAIwPsYJXuuaiDBs1aMgALpd28YxROO1OY/KRyQNCJ
HRYMHi3vhA24+xTJucZGTC31p0USHMfnwnCmtfWRnNuiqunL/IHaImJKv18NuZC3
CtTMdIhtPiZZI0LpHjxoU/ONG/4x5BKHo6tOOJ3NWc8ulDAOGCyjymsywdeSZOy5
X8CQWxixVh48Xgo4OwKeexQDh0bCQtQCyqZbv2M762yFkAntpdmeaaV2CoKEAmVJ
9FVN07Oe7cdt7pUUA7Twpp45yAypOHDaOoEWSX29/Quourkr5FFGMyYd99QtJ/VA
FnTweeX7v/EzbkgSEfnEDMlXEAD3Zm/3esZNczcL902H/JSSNh/00S5XFXHgEuRi
X4ptEEMr/3fZ7Jet3LeMcZo6it5hwHSDTkmcmAXNSGfRCSvha8hgage277aP6UYe
oBMd4qEvXd+QJw2WWtXxbZkNoYWFZopoVdoS1Fzr7LlDGgPuDNEL6qEFbAnV9UK+
l/qOOtubM2rYXwBssOxYrREDXRaKAD+qQ+ZH/y4zaA2RvH/aItS2J5SBvky/9aw7
90G6hJnX54DpzDEW/YTj
=2T5D
-END PGP SIGNATURE-

Bug#831271: (no subject)

[Barry Warsaw]

How would we do that?  I'm not particularly fond of debian/control.in files.

Bug#842732: python-pip: Fix autopkgtests

[Barry Warsaw]

Package: python-pip
Version: 8.1.2-2
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear Maintainer,

There are some latent autopkgtest failures now, as originally
described in LP: #1626258, which also contains a debdiff.  As per
usual, this should be fixed in Debian and resync'd in Ubuntu.

https://bugs.launchpad.net/ubuntu/+source/python-pip/+bug/1626258/comments/14


- -- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.7.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages python-pip depends on:
ii  ca-certificates  20160104
ii  python-pip-whl   8.1.2-2
pn  python:any   

Versions of packages python-pip recommends:
ii  build-essential12.2
ii  python-all-dev 2.7.11-2
ii  python-setuptools  28.0.0-1
ii  python-wheel   0.29.0-1

python-pip suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIcBAEBCAAGBQJYF5h+AAoJEBJutWOnSwa/VAQP/2JSkMKEg7bKl1d1UwbVha14
9gN/mwSLSd+ypJhARCoQ2N/w/pQFn2NTGYdmBraSsvKR6xWahcVKn2+x7poGMAmT
Es7O6LfCzmYtz2S7fTLSlU4VSXJK8w1RHsRpfRUWoEKvXtJJ31DSWLeUQfoUgIUm
GFgCI1zz+usitncRAagbxQOhhxDsnDR0bnqyhKVclNIvZ4BJG3xyNJLWAvgZuUb0
krk7zr7pBWGMY2zNbM4PI7m0F8RSwbLeUHfPNOG/pamvswEh1zjhEnfT+JBmXEUu
+zuMZQjcolXyQb9kfHaLCSSLBNf3uFlHbLuI0HTI+c9rmhZ92jjMX8J1A7LIMvny
/mrq+fzDMrOtfD2oEQ7cGWp/v6tOqxSC70ImrBfSDHaecrenOss2hpOv/0jmzzXq
QYUa+UjpQ1BT4bUUZ1MLby8UyYTfEjKc9fbh04StMvE3vuxGY3FcfSkqLdtzl/K+
ls++YHHe4xKhFZKPN0C0w+lrECyFL4XDlfcUZkEAB1M0D9feVwlfdrXZfduS/Omw
jkoI9TX5riN9CzuyNUm+Ji9oCQM2SAS/AnsLDlONJn4cEKxa1sjt8lmea5EDEuqx
+c5/qPUWtv7VHKWgX97cmZ4x2YdPo0oPcozDU6AgD7eaAQV2LAGBxsdvqkfWoM+C
tmFW1rzDjjcuf+elgBYo
=glN2
-END PGP SIGNATURE-

Bug#840847: (no subject)

[Barry Warsaw]

Any chance this fix can get uploaded soon-ish?  gtimelog build depends on it
so it's marked for autoremoval because of this bug.  Thanks!

Bug#840084: [Python-modules-team] Bug#840084: python-virtualenv: “Multiple .dist-info directories” when creating virtualenv

[Barry Warsaw]

On Oct 08, 2016, at 04:58 PM, Ben Finney wrote:

>When attempting to create a new virtualenv, Pip crashes with an error:

I can't reproduce this on unstable.

% python2 -m pip --version
pip 8.1.2 from /usr/lib/python2.7/dist-packages (python 2.7)
% python2 -m virtualenv --version
15.0.3

% python2 -m virtualenv /tmp/p2
Already using interpreter /usr/bin/python2
New python executable in /tmp/p2/bin/python2
Also creating executable in /tmp/p2/bin/python
Installing setuptools, pkg_resources, pip, wheel...done.

% python3 -m virtualenv /tmp/p3
Running virtualenv with interpreter /usr/bin/python2
New python executable in /tmp/p3/bin/python2
Also creating executable in /tmp/p3/bin/python
Installing setuptools, pkg_resources, pip, wheel...done.

Something Else must be going on in your environment.


pgp6AQ9fZOUKc.pgp
Description: OpenPGP digital signature

Bug#839253: autopkgtest: --testname incompatible with Test-Command:

[Barry Warsaw]

On Oct 01, 2016, at 12:16 AM, Martin Pitt wrote:

>You can actually -- they get named "command1", "command2", etc, same
>names that appear in the logs and in summary.

I must have missed that, but it's really nice.


pgpIUkqcn_THD.pgp
Description: OpenPGP digital signature

Bug#839253: autopkgtest: --testname incompatible with Test-Command:

[Barry Warsaw]

On Oct 01, 2016, at 12:16 AM, Martin Pitt wrote:

>I'd slightly change that idea to be Test-Command-foobar:, to provide
>an optional name? Test-Command: would then continue to get
>autogenerated commandN names.

I rather like that.  One of my other minor problems is that in the summary, if
you have a lot of tests, it's a bit difficult to map 'test command6: ...' to
the actual test that ran.  You have to scroll back quite a bit to look those
up.

So if we had Test-Command-foobar and the summary output at the end said

'test foobar:'

then I think that would be a nice improvement!


pgpg749aRT5U1.pgp
Description: OpenPGP digital signature

Bug#839253: autopkgtest: --testname incompatible with Test-Command:

[Barry Warsaw]

Package: autopkgtest
Version: 4.0.5
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear Maintainer,

AFAICT, if you specify a test with Test-Command: there's no way to
select it with `autopkgtest --testname`.  A couple of thoughts:

* Allow Tests: and Test-Command: to coexist.  In such a case, the
  Tests: field would be used for --testname matching while the actual
  tests would run from Test-Command:
  
* Add a Test-Name: field solely for the purpose of matching
  --testname.  Of course if Test-Name doesn't exist, it would fall
  back to matching on Tests:
  
* Allow --testname to match on patterns.  Thus if I had a stanza that
  looked like:
  
  Test-Command: tox -e qa
  Depends: @builddeps@, git
  
  I could run that with --testname=qa

Other thoughts of course welcome!  Or did I miss something?


- -- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.7.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages autopkgtest depends on:
ii  apt-utils   1.3
ii  libdpkg-perl1.18.10
ii  procps  2:3.3.12-2
ii  python3 3.5.1-4
ii  python3-debian  0.1.29

Versions of packages autopkgtest recommends:
ii  autodep8  0.8

Versions of packages autopkgtest suggests:
pn  lxc  
pn  lxd-client   
pn  qemu-system  
pn  qemu-utils   
ii  schroot  1.6.10-2+b1

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIcBAEBCAAGBQJX7qwnAAoJEBJutWOnSwa/whsP/jbbENZ+nr2Gs2Kzy6ln/8Jw
FVyvifpxea1pwUWxF4wOC9YLEAJbLOlAXkD6VSxkIyicOndkcSwX4YG59H/YgyKF
3i6IVTVgcS6vN+FNSIOc8eU+9+V9ibv1+HS6u0MnV7Ab60PI7Z9dyuPm2gv3BZh8
i1+of8gM/YLRKK+sZoh4D2sPjk8qy9oyjwlJaiA8Vy2RvrdSLSGB6qf61ra2owfM
RxsjQFAAw93kkS7LdT/15PNI+xgYvSAwT5fGMJYfZB+qE4JEZfSjQZnNv1BDHj+m
b1PbWhuNIL41qliQNCBiaUq4KWRHDcz68YYqr23WQQCC+pzJospdHOYVXPrBJxtL
eMqRH0xl6V0iep1VA7r+l47G57IDXMlejgV2kZKURmhD9/tQDxq4SUF+NK0Q/Pz6
Cj621eF1LUxyfhai3Uw1sHlan5gLO7YkR1UEVEcV17c6pRewWOQgd+CiQBfaoD1W
ScwFBB/c/CyUaaYeo0qbwxCJQq4DVBf8QyyZprorZrG9WHOLmQQl5DxewpvyDd+O
XpaXokOGbJwTmprQ8tXNjIJ8fGafvX2chVJo5CriMspBfFL7Q4frvVzZtixIGS4E
aplNE1s/VbxwVReWPLKHMRit+eR5hlqW9Jp6/ulQOyqOcuLaYAilcJtF7sLb6i5b
pxDnKdFy2i70Mv/7d1fr
=Z/0G
-END PGP SIGNATURE-

Bug#839072: autopkgtest: Allow for GitHub-style PR urls

[Barry Warsaw]

On Sep 28, 2016, at 04:52 PM, Martin Pitt wrote:

>First, thanks for working on this! I'd love to make it straightfoward
>to test a github branch with a single autopkgtest invocation.

Seems pretty easy!  Attached is the patch.  I tested this with both GitHub and
GitLab branches and pull/merge requests.  E.g. all the following work nicely:

$ autopkgtest https://gitlab.com/user/project.git
$ autopkgtest https://gitlab.com/user/project.git#branchname
$ autopkgtest https://gitlab.com/user/project.git#merge-requests/1/head

$ autopkgtest https://github.com/user/project.git
$ autopkgtest https://github.com/user/project.git#branchname
$ autopkgtest https://github.com/user/project.git#refs/pull/1/merge

Each stanza above describes the master branch, a specific other branch, and
the respective hosting services' names for pull/merge requests.
From 0a7a2a4a5918677237ea2ae57befec2bd443aee9 Mon Sep 17 00:00:00 2001
From: Barry Warsaw <ba...@ubuntu.com>
Date: Wed, 28 Sep 2016 13:08:58 -0400
Subject: [PATCH] Support url#refspec format.

First, I fixed the bug in the previously supported url#branch syntax,
where the code expected a space separator but the documentation
described the # separator.

Next, this generalizes the approach so that GitHub style PR refspecs,
e.g. refs/68/merge also work after the #.  Since the code paths are
identical now, we get both for free.
---
 runner/autopkgtest | 23 +++
 1 file changed, 15 insertions(+), 8 deletions(-)

diff --git a/runner/autopkgtest b/runner/autopkgtest
index 8b583cf..d45696e 100755
--- a/runner/autopkgtest
+++ b/runner/autopkgtest
@@ -389,14 +389,14 @@ def build_source(kind, arg, built_binaries):
   'if [ -n "$RC" ]; then if echo "$OUT" | grep -q "Unable to find a source package"; then exit 1; else exit $RC; fi; fi;'
   'echo "$OUT" | grep ^Get: || true' % {'src': arg})
 elif kind == 'git-source':
-fields = arg.split()
-if len(fields) == 1:
-create_command = "git clone '%s' || { sleep 15; git clone '%s'; }" % (arg, arg)
-elif len(fields) == 2:
-create_command = "git clone --branch '%(b)s' '%(u)s' || { sleep 15; git clone --branch '%(b)s' '%(u)s'; }" \
-% {'b': fields[1], 'u': fields[0]}
+url, sep, branch = arg.partition('#')
+create_command = "git clone '%s' || { sleep 15; git clone '%s'; }" % (url, url)
+if sep == '#':
+# This is url#branch or url#refspec (for pull requests).
+fetch_command = "git fetch -fu origin '%s:testbranch' || { sleep 15; git fetch -fu origin '%s:testbranch'; }" % (branch, branch)
 else:
-adtlog.bomb('--git-source argument must be "URL" or "URL branchname"')
+# This is just a plain url.
+fetch_command = None
 
 testbed.satisfy_dependencies_string('git, ca-certificates', 'install git for --git-source')
 else:
@@ -419,10 +419,17 @@ def build_source(kind, arg, built_binaries):
 create_command,
 'chmod -R a+rX .',
 'cd [a-z0-9]*/.',
+]
+if fetch_command is not None:
+script.extend([
+fetch_command,
+"git checkout -qf testbranch || { sleep 15; git checkout -qf testbranch; }"
+])
+script.extend([
 'pwd >&3',
 'sed -n "1 {s/).*//; s/ (/\\n/; p}" debian/changelog >&3',
 'set +e; grep -q "^Restrictions:.*\\bbuild-needed\\b" debian/tests/control 2>/dev/null; echo $? >&3'
-]
+])
 
 (result_pwd, testpkg_name, testpkg_version, build_needed_rc) = \
 source_rules_command(script, 'extract', results_lines=4)
-- 
2.9.3



pgpmyqftHRebM.pgp
Description: OpenPGP digital signature

Bug#839072: autopkgtest: Allow for GitHub-style PR urls

[Barry Warsaw]

Package: autopkgtest
Version: 4.0.5
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear Maintainer,

As we've been discussing, it would be nice if you could run
autopkgtest against GitHub-style pull requests.  There's no direct URL
that would allow you to do this, but you can support this by doing a
git fetch after the initial clone, e.g.:

$ git clone https://github.com/CanonicalLtd/ubuntu-image.git
$ cd ubuntu-image
$ git fetch origin +refs/pull/68/merge
$ git checkout -qf FETCH_HEAD

So the idea then is to allow URLs that can additionally specify that
PR ref.  Then I could run autopkgtest like so:

$ autopkgtest 
https://github.com/CanonicalLtd/ubuntu-image.git+refs/pull/68/merge -- schroot 
yakkety-amd64

Notice the '+' separating the .git URL from the PR refspec.

I'm not sure this is the best possible syntax, and I'd like to be able
to support GitLab PRs too, which apparently don't use a + or the same
refspec for their merge requests, although the same general
implementation (clone then fetch) *should* work.  

I thought about maybe using a '@' or some other unexpected delimiter
to separate the .git URL from the PR specification.  I'll play with a
GitLab MR to see what works best, but that would be an easy change.

I have a hack that works for GitHub, which I'll send along shortly.

- -- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.7.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages autopkgtest depends on:
ii  apt-utils   1.3
ii  libdpkg-perl1.18.10
ii  procps  2:3.3.12-2
ii  python3 3.5.1-4
ii  python3-debian  0.1.29

Versions of packages autopkgtest recommends:
ii  autodep8  0.8

Versions of packages autopkgtest suggests:
pn  lxc  
pn  lxd-client   
pn  qemu-system  
pn  qemu-utils   
ii  schroot  1.6.10-2+b1

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIcBAEBCAAGBQJX69L6AAoJEBJutWOnSwa/YUsQAKHzOSkuu509bpjX7tKJ4M19
4erLTGuF5yoUBgC79yNGEt0x5AvidsCuV/xeSCiyzbDXkU9sO/D48Wyq+CVUdxUr
kzDh4wORDFp0VhDo3maci8JnHu+Ng5nQ37JR+iQTk4Xd/abaiFMpADhU5DHDCO11
naHdOwsms26S+O/83zKujkxUHujOFMrv1Y+cvCc7lfuOgK4plBQh0LIc7bi3vFjn
zjFBtflyVRK1qBMROgQLJgq+Ijz6507Uf5hf317pwt5XjZk+/GBF2sRu0e7LTXxC
6GvpPgCQv4ru70OBrgzw8uj/aClb1IDg20CDEij+dwehGh97WkpqT5200V4V+OX0
4iRiMbOaMPtAzTBN1V3qlOLkIKSP1KlkRT86J6/+jYBReMZeXXDlf10WdaKjkMA/
yIQUfMIQfTPgSNl2NxGvxHF3EED9JXAGJuObHcqPiQTdI9wBkjOIlsSf5nwQkteF
Tp9BpfleTomgPVpwv1yxVDdqvoOT8OPVxVCE9tgOiSpG1Bad8y7CMmW9X4TgHA80
DWglHel6RtS0ihAol1gzeOiB79lQcpSEW3+8ill2b3I4K2s/is3iUlvqX8zRCzKS
Ckw62mCDPLGBZM19NbJxMHrjqmeVIxjlWtWrZoqoP5vqSRagcS/TpxczYJA2p4VS
xqaX2k7Kc7VB2zvnShjS
=p5rd
-END PGP SIGNATURE-

Bug#838531: nose2: FTBFS in testing (failing tests)

[Barry Warsaw]

On Sep 24, 2016, at 03:47 PM, Chris Lamb wrote:

>> nose2: FTBFS in testing (failing tests)
>
>This is somewhat mind-bending to debug:
>
>   AssertionError: Regex didn't match:
>  'FAILED \\(failures=5, errors=1, skipped=1\\)' not found in
>  […] FAILED (failures=1, errors=1, skipped=1)\n'
>
>ie. the wrong tests in a set of tests for a testcase in a testing utility
>are passing when they should be failing, and it's not even clear which of
>them should be failing.

Hi, I can't seem to reproduce this on unstable.  Both dpkg-buildpackage -A and
sbuild work just fine, as does autopkgtest in an unstable chroot.

However, the reproducible build problem is a real issue; I'm about to upload
0.6.5-2 which will fix this.  Once that's pushed to git or uploaded, could you
please try again?

Bug#838663: tox: python3 pip is called "pip3" in Debian and tox should call that instead of "pip"

[Barry Warsaw]

On Sep 23, 2016, at 02:37 PM, Ximin Luo wrote:

>In Debian we have "pip3" but tox hardcodes an invocation to "pip".
>
>The attached patch fixes this; it should definitely be forwarded to upstream
>as well.

Hi and thanks for the report/patch.  Can you provide a reproducible failure
that this bug fixes?

Bug#838559: python-pex: tests started to fail on "Connection refused"

[Barry Warsaw]

On Sep 22, 2016, at 12:10 PM, Martin Pitt wrote:

>This does not depend on Debian vs. Ubuntu or container vs. qemu or
>whether the test environment uses a proxy by itself. It can trivially
>be reproduced locally with the schroot runner:
>
>  autopkgtest --testname execute.sh python-pex -- schroot sid

It's a bit worrysome that this *doesn't* fail in my normal dev box's sid-amd64
chroot.  I've reproduced it on other machines though.  I suspect that
something in setuptools 25.2.0 broke the assumptions that no network access
would occur if the module could be satisfied locally.  That's specifically why
textwrap is used (a stdlib module) and catching that is the reason why the
discard port proxies were added, so at least they've done their job. ;)

Anyway, failure confirmed.


pgpUFe3JEpWH6.pgp
Description: OpenPGP digital signature

Bug#838379: dpkg-dev: Add Testsuite: autopkgtest when a debian/tests/control.autodep8 exists

[Barry Warsaw]

Package: dpkg-dev
Version: 1.18.10
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear Maintainer,

I have a Python package that only contains a d/tests/control.autodep8
file, not a d/tests/control file.  This requires the addition of an
explicit Testsuite: autopkgtest-pkg-python header to d/control whereas
the existance of d/tests/control would add this automatically.  IWBNI
the same logic applied to d/tests/control.autodep8

- -- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.7.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dpkg-dev depends on:
ii  base-files9.6
ii  binutils  2.27-8
ii  bzip2 1.0.6-8
ii  libdpkg-perl  1.18.10
ii  make  4.1-9
ii  patch 2.7.5-1
ii  tar   1.29b-1
ii  xz-utils  5.1.1alpha+20120614-2.1

Versions of packages dpkg-dev recommends:
ii  build-essential  12.2
ii  fakeroot 1.21-2
ii  gcc [c-compiler] 4:6.1.1-1
ii  gcc-6 [c-compiler]   6.2.0-4
ii  gnupg2.1.15-3
ii  gnupg2   2.1.15-3
ii  gpgv 2.1.15-3
ii  libalgorithm-merge-perl  0.08-3

Versions of packages dpkg-dev suggests:
ii  debian-keyring  2016.09.04

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIcBAEBCAAGBQJX4W7cAAoJEBJutWOnSwa/kHsP/2B383SMNwWceW0P7PpcaWa2
+q6jLhsi5k1I83A9Dc7fKqJU+YaZCyhWyWkgR2Ka1kBX4YhwDpcqA4ed4HtG5h8J
tKSZWeId/HBdw/QGvjpocSoeeN6M/eCs6q6YmFn9e0DVj2BwRmrTQ9Rxx4diNBLv
3x/jGRUG/gfNoXffdpNvurad9EP3oO3u8e9jIfZCsoC7lSx/T3uHP+nyj3kLYDec
umEB9I40MNbdxRgLXn4+ukwJ7xrmjRAcc5Y6r/oZTrfhyjlYZP43UnPA14KtT0Ji
a/jKF2F7Ryh9vNVXyoRvCUjvpNM9cJLmBXCfJSdPRifSUgrevwLJW6lMY99bRlF0
DY65dYLuZjOKjzC0NqEDlbW5+LhlRs8sL/480v61Kgz1DWf/OOV3g57+Vp93H6fk
oD0o2Ms984cGYv/uO01MmMfjO6Mf1V1Z+PSjlOVI2VhRV0zHLbioTiAdTuFIMG2c
Daa5i3WIP5jdwHY+ZuEygmpNrABmDIfcqNPbc+C+vuvL5Jl/pD32CGbt9soKFwv+
S5KtsPD2V7s+yBJ5jtyXGW2s0nh+Iwc3vxCHeaEbofbBftnuzUZ4t//i65tMwFiz
/g3RMUJK55njv3hpxvDfFYU/l3Qa2QLpn+REjGv3YiSECcgUquBKfvyI2YbpXjCx
4TsDZEn1fbIotLVzCzVB
=s0pk
-END PGP SIGNATURE-

Bug#838189: The name "tox" is fully misleading and should be better "python-tox"

[Barry Warsaw]

On Sep 18, 2016, at 09:56 AM, Klaus Ethgen wrote:

>I set this bug to normal instead of wishlist as it currently blocks
>somehow packaging of other packages.

What other packages does it block, and how exactly does it block them?

>The name "tox" of this package is extremely misleading as normal use
>associate [0] with this name.

I'd quibble with these characterizations since the Python testing tool named
tox appears to predate the instant message tool named tox by many years.  I'd
claim that it's unfortunate that tox.chat chose a name which is very common,
and with a long history in another context.

>More over, it is somewhat python specific so it is better named python-tox.
>While it might be possible to work around the packaging block, that would
>produce a complete mess. So I ask you to please rename the package (back) to
>python-tox. I believe that this will take some time so please don't defere it
>to long.

I don't want to make life difficult for you, but I'm highly resistant to
changing either the package name or the executable name.  I'll wait for your
response, but I intend to close this bug as wontfix.


pgp96hovhsD05.pgp
Description: OpenPGP digital signature

Bug#823922: (no subject)

[Barry Warsaw]

It's difficult to figure out the copyrights on many of the files in examples.
I've asked upstream for details.

Bug#832616: [Python-modules-team] Bug#832616: virtualenv: Doesn't seem to know what version it runs under

[Barry Warsaw]

On Jul 27, 2016, at 05:06 PM, Matijs van Zuijlen wrote:

>virtualenv allows specifying the python version to use. However, when
>doing so I get the following output:
>
> $ virtualenv -p /usr/bin/python3 --system-site-packages .venv
> Already using interpreter /usr/bin/python3
> [..]
>
>It seems to indicate I didn't need to pass in the python interpreter to
>use.

This message is telling you that the -p option is exactly the same path as
sys.executable.  Basically when virtualenv is invoked with a -p that isn't
sys.executable, it will re-exec itself with the requested interpreter.
However, in Debian, /usr/bin/virtualenv is shebanged to /usr/bin/python3 even
though the default -p option is still /usr/bin/python.  This is why you don't
get this console message with the default invocation.  Generally virtualenv's
shebang is unimportant.

I agree the warning is a little confusing, but I don't think it's worth
changing in Debian.  I'm not even sure it's worth reporting upstream.

You can just safely ignore the message.

Bug#828883: (no subject)

[Barry Warsaw]

This actually turns out to be a bug in pybuild (dh-python).

In zope.interface's d/control file we have:

Build-Depends: debhelper (>= 9),
   dh-python,
   dpkg-dev (>= 1.16.1~),
   libpython-all-dbg,
   libpython-all-dev,
   libpython3-all-dbg,
   libpython3-all-dev,
   python-all-dbg:any,
   python-all-dev:any,
   python-setuptools,
   python-zope.event,
   python3-all-dbg:any,
   python3-all-dev:any,
   python3-setuptools,
   python3-zope.event

Note the ':any' specifier on the interpreter packages.  pybuild didn't
recognize these.

I reported this to Piotr who fixed it in dh-python git, which I tested and
verified fixes the problem, so I reassigned this bug to that package.

Bug#830892: [Python-modules-team] Bug#830892: python-pip defaults to --user, breaks upstream --target option

[Barry Warsaw]

On Jul 12, 2016, at 05:41 PM, Daniel Holth wrote:

>The problem is that Debian patched pip to make the --user option the
>default.

In talking with Donald, we all agree that we need to move forward on the
upstream switch to --user by default.  I don't have time right now to continue
working on that, but I would love to drop our patch, and this is the best way
to do it.

Bug#828094: python3-coverage: Missing JavaScript dependency: jquery.debounce.min.js

[Barry Warsaw]

On Jul 03, 2016, at 09:04 PM, Ben Finney wrote:

>I can work to package the library dependency; would you be interested
>in sponsoring it into the archive?

Yes, for sure!


pgpKn2YszV_ST.pgp
Description: OpenPGP digital signature

Bug#828094: python3-coverage: Missing JavaScript dependency: jquery.debounce.min.js

[Barry Warsaw]

Package: python3-coverage
Version: 4.1+dfsg.1-2
Severity: grave
Justification: renders package unusable

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear Maintainer,

Apparently python-coverage has gained a dependency on
jquery.debounce.min.js but this isn't available in the archive afaict.
The closest thing apt-file tells me is

% apt-file search jquery.debounce
phpmyadmin: /usr/share/phpmyadmin/js/jquery/jquery.debounce-1.0.5.js

See the reference in coverage/html.py.

This missing js file breaks html reporting.  E.g. in a tox
environment using system site packages:

coverage runtests: commands[1] | python -m coverage combine
- --rcfile=/home/barry/projects/ubuntu/allsnappy/ubuntu-image/coverage.ini
coverage runtests: commands[2] | python -m coverage html
- --rcfile=/home/barry/projects/ubuntu/allsnappy/ubuntu-image/coverage.ini
Couldn't find static file 'jquery.debounce.min.js' from
'/home/barry/projects/ubuntu/allsnappy/ubuntu-image', tried:
['/usr/share/javascript/jquery.debounce.min.js',
'/usr/share/javascript/jquery-debounce/jquery.debounce.min.js',
'/usr/lib/python3/dist-packages/coverage/htmlfiles/jquery.debounce.min.js',
'/usr/lib/python3/dist-packages/coverage/htmlfiles/jquery-debounce/jquery.debounce.min.js']
ERROR: InvocationError:
'/home/barry/projects/ubuntu/allsnappy/ubuntu-image/.tox/coverage/bin/python
- -m coverage html
- --rcfile=/home/barry/projects/ubuntu/allsnappy/ubuntu-image/coverage.ini'


- -- System Information:
Debian Release: stretch/sid
  APT prefers yakkety
  APT policy: (500, 'yakkety')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.4.0-25-generic (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages python3-coverage depends on:
ii  libc6  2.23-0ubuntu3
ii  python33.5.1-4
ii  python3-pkg-resources  20.10.1-1

Versions of packages python3-coverage recommends:
ii  libjs-jquery  1.12.3-1
ii  libjs-jquery-hotkeys  0~20130707+git2d51e3a9+dfsg-2ubuntu1
ii  libjs-jquery-isonscreen   1.2.0-1
ii  libjs-jquery-tablesorter  10-2ubuntu2

python3-coverage suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJXbbpCAAoJEBJutWOnSwa/L4IQAJa1TXw6WmfwoT6aX82Qv6x8
0+Jk0aNE3aHP5DSaJTBhVP4i1WciKt6mvrubM/+uARpsGFFR9Rz61YDtkk59NwGL
gcU7wpmhN/d9yhn7l3XcUTpx3aiqq6l86/HQg45dLNL7LK23Ntsq+fNTrbtw+6qp
0FCFC0ZT6qN9LtV+dpV7MbW3rTuYFrqo98G7xSlOZrWkA2V8gO5mTbDUkq+y1e/O
kk3mft9XUu5j8JI87i1SgjdXrcLJGchKW2Z2MkqhuFPOCbg2PY/FlJZNLnQEqwhd
JDsDYV+4Qh7n3QwDmotpkR98GEZecHkI6kVRcP2j3/UDxojmeMfr2Zw3k5PJnhMf
ETqy7a9w8medl9qPNCR+EIf/f+akuk0m5IEJJT9MjagifEg0bZtUomame619r63d
aQY5beJnpIldg+N0x4q7R1tXx5tTrnGipBjRQrZPRC2m5acHMQZzm58uQ3ASAeXE
JTl4o4P00q4t7nEX7mjWiUI1AFjwITGKDoGrzBOPTzikH3tVakNM/o2yG4DkUUtD
U0M9nhycdiEw/5pBs2MhJ70ZJ40v7sG2RQ8Jxv7eQcwTuyXlSNAe7cIOVHPrB/kz
jtRc3fniGaWX0yVHtuMIDa1BvrhvagDuihGNmveVNBVS4OPCoxvRyGgjSqm9Sbx7
wccdJBWySpvfr/BYs7m3
=QNgz
-END PGP SIGNATURE-

Bug#827464: python-coverage: Please add usage DEP-8 tests

[Barry Warsaw]

Package: python-coverage
Version: 3.7.1+dfsg.1-1+b2
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear Maintainer,

After a recent review, I noticed that DEP-8 tests have been added
which do import tests.  It would be useful to also add tests which
check for run-time functionality of the installed packages.
Specifically that the following commands run and produce useful output:

$ python-coverage foo.py
$ python3-coverage foo.py
$ python -m coverage foo.py
$ python3 -m coverage foo.py


- -- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.6.0-1-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages python-coverage depends on:
ii  libc6 2.22-11
ii  python2.7.11-2
ii  python-pkg-resources  20.10.1-1

Versions of packages python-coverage recommends:
ii  libjs-jquery  1.12.3-1
ii  libjs-jquery-hotkeys  0~20130707+git2d51e3a9+dfsg-2
ii  libjs-jquery-isonscreen   1.2.0-1
ii  libjs-jquery-tablesorter  11-2

python-coverage suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJXYpVcAAoJEBJutWOnSwa/YjcQAJNArv4kuH//bEPEUFAoC+lT
KJXPX09n/mgbcnaZsnF5za2powxDISNRqrHVt1Su8uWxTFR3XC8zXvYGG4ejZHHb
jfv4a5yIrrBJP3Atxyq6LB2+BQGNX4pyO/bOb/s14ZZxOaEZ6sPH9rEfCLXu5RVT
j/32aAwByBpUV4EGw13EXAaOqg1etDbkJ5vDKX/UzDT3VXJb6hfSEcOJMX1MVL+8
Ra4/vFxXGoKnCsbvViSJwzb78S3Z/+wrQW2oKKWJiM9REo4J5b184cB/FbXPSFte
CaWanzxRmxb3+YXIPAtyrbgIT88rAqmH2tnDKEJtTZ4lTWgB0Um8Gj/R8Hjl0srj
Bskj2KikSLdVIcO/MOOrH49HW1QCHaI9nOnHR4CCff9PSZjqHkuYAqR5lvQhzCKz
Ah4TUdLwZ8RB1h7+T9F2hrG5fpaPNxQ4I8iBUxONVh6Rm4CMRpHfLj6rtiqzBzau
9Bl+whohlL7CWuy8mJlHXCOBm8l7y00vv2MfVt0ITXWJdfaCjV77ga+6WsGLFrIu
6JA2rFgZmYEU0lbdWPkW8OCfTNL3dOMGqUsPftd220rEKF+ClXzU5MWZW9rnzQ8/
N6cTowixsCSzaNYcGVmldQHzokwBl00CmbwipXIcAmc0Q9M6gZAj8GLQXYLtz6lD
D9447whxWk/361KRVFPs
=yL35
-END PGP SIGNATURE-

Bug#825112: (no subject)

[Barry Warsaw]

On Jun 08, 2016, at 10:23 AM, Gordon Ball wrote:

>I don't see anything locally, but I do see it when uploading a binary
>package to mentors.d.n - I'm unsure how their setup differs from
>`lintian --pedantic`. Anyway.

Interesting.  Oh well, that's why version numbers never run out. :)

>If you think it looks in good shape, let's go for an upload. Thanks for
>your time reviewing the packaging.

Awesome!  I'll upload it now.  I can't wait to start using it for real.
Thanks for all your great work.


pgpjbmCWhweSg.pgp
Description: OpenPGP digital signature

Bug#825112: (no subject)

[Barry Warsaw]

On Jun 07, 2016, at 10:00 PM, Gordon Ball wrote:

>> The packaging looks really good.  I noticed the setting of http_proxy in
>> override_dh_auto_build.  You probably don't strictly need that because I
>> believe pybuild does that automatically.  It can't hurt though and some
>> maintainers prefer to be explicit about that.  
>
>The http_proxy bit was cargo-culted from
>https://wiki.debian.org/Python/LibraryStyleGuide

Ah, I'd forgotten that this was still needed for sphinx-build.

>Good idea. The test suite is extensive but it hadn't occurred to me that
>it is entirely based on importing it as a library rather than actually
>running the binary. I'd tested the installed package but clearly on a
>system with python3-pkg-resources already installed.
>
>I found that this fails in an autopkgtest schroot though - xonsh fails
>to start if $HOME is not writable (which is possibly a bug), so I've
>added a wrapper which sets $HOME=$ADTTMP (and added a couple of extra
>examples).

Looks great, much better than my quick hack. :)

>On hold for the moment then. I'm happy to have it listed as team maintained
>at a future point though. I'm already subscribed to debian-python, I'll apply
>to join the relevant teams soon.

Cool.  It'll be easy to move later.

One possible minor issue is that DPMT did adopt git-dpm for packages, but
since that decision several years ago, git-dpm has apparently stopped being
developed.  It hasn't quite bitrotted yet, but I am advocating that DPMT drop
git-dpm and use gbp-pq for patch management.  I don't see any reason other
than (hopefully temporary) consistency for PAPT to adopt git-dpm once that
switch happens.  We'll have to see what the team says.

For now, let's just assume gbp-pq will be adopted for PAPT.

>Given the script is generated based on `entry_points` in setup.py,
>shouldn't this dependency be generated by pybuild/dh_python?

Actually, that should come from an install_requires section or a
requirements.txt file.  I don't see either of those in the xonsh repo.  But
also pkg_resources is kind of a special case on Debian.  It really comes as
part of setuptools, but in Debian we split it out into a separate binary
package, so I don't know that it would be automatically detected in any case.
Clearly it doesn't since it crashes without an explicit Depends, but we'd have
to ask Piotr on debian-python@ to know whether that's intended behavior or
not.  TBH, I always just add it explicitly.

>There are a couple of remaining (possibly non-) issues:
>
> * lintian reports privacy-breach-generic on the documentation (google
>webfont links). I can't see this explicitly configured anywhere in the
>rst files or conf.py, so I *think* this is being added by
>sphinx/cloud-sptheme

Interesting.  I built the package from the git repo on unstable and ran
lintian over the amd64.changes file.  I don't get any lintian warnings.

> * building the documentation generates (I think) inconsequential errors
>since the xonsh pygments lexer is not available at build time; this
>could be fixed by build-depending on itself, but I'm not sure this is
>worth adding a dependency cycle for.

I see that too.  Agreed it's probably not worth worrying about right now.

> * xonsh supports installing itself as a jupyter kernel, which I'm
>interested to include but for the moment (parts of) jupyter is only in
>experimental, so it can probably wait until a future xonsh upload

+1

Everything else lgtm.  Let me know when you want me to sponsor an upload; I'm
happy to do it any time.  It will have to go through NEW of course, but it
would be nice to get this into peoples hands soon.  (I know I'm not the only
Debuntunista who wants to use it after watching the Pycon talk. :)


pgpxquwJZvesq.pgp
Description: OpenPGP digital signature

Bug#825112: (no subject)

[Barry Warsaw]

On Jun 07, 2016, at 10:35 AM, Gordon Ball wrote:

>Packaging has been done and can be found in collab-maint [1]
>(git-buildpackage+pristine-tar format [2]). Current version is
>0.3.3+dfsg. Builds for xenial/yakkety can be found in a PPA [3].

Cool.  I grabbed and looked at the collab branch.

>The packaging and test suite appear to work, but I've held off trying to
>get it uploaded since there have been several minor versions in quick
>succession recently (0.3.0 .. 0.3.3 in the last two weeks) and I was
>waiting to see if it would settle.

Hopefully that will calm down after the rush of Pycon.

>Would you be willing to review and possibly sponsor?

For sure.  Would you consider adding me to Uploaders?

The packaging looks really good.  I noticed the setting of http_proxy in
override_dh_auto_build.  You probably don't strictly need that because I
believe pybuild does that automatically.  It can't hurt though and some
maintainers prefer to be explicit about that.

It might be good to add an autopkgtest that actually runs the installed xonsh
as a sanity check.  Maybe even just run a simple xonsh script?  See below.

Should debian/xonsh.1 be generated from help2man so it doesn't get out of
sync?

>[2]: This should probably be under DPMT and git-dpm, but I'm not (yet) a
>team member

You should definitely join debian-python!  However, as this is an application
and not a library, it would probably be best to put it under PAPT.  The
problem there of course is that PAPT hasn't switched to git yet :(.  I'm
hoping tumbleweed and others might make that happen at or after debconf2016.
Until that happens, collab-maint is fine.

>[3]: ppa:chronitis/misc (contains a variety of other stuff)

Cool!

/me builds

Love the logo output during `python3.5 setup.py clean` ;)

I think you need to explicitly depend on python3-pkg-resources, otherwise:

# xonsh
Traceback (most recent call last):
  File "/usr/bin/xonsh", line 5, in 
from pkg_resources import load_entry_point
ImportError: No module named 'pkg_resources'

I made a few of the suggested changes (adding the Depends and an autopkgtest)
and pushed it to the `review` branch on collab-maint.  Let me know what you
think.  Great work, and I'm happy to sponsor and/or comaintain xonsh!


pgpMA5iuifa1M.pgp
Description: OpenPGP digital signature

Bug#825112: (no subject)

[Barry Warsaw]

Just wondering if anybody's made progress on this.  I was blown away by the
talk on Xonsh at Pycon 2016 [*] and of course the first thing I did was look
for it in Debian. :)  I'd be happy to help package this up.

[*] https://www.youtube.com/watch?v=uaje5I22kgE

Bug#824659: ITP: python-public -- @public decorator for adding names to __all__

[Barry Warsaw]

Package: wnpp
Severity: wishlist
Owner: Barry Warsaw <ba...@debian.org>

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: python-public
  Version : 0.2
  Upstream Author : Barry Warsaw <ba...@python.org>
* URL : https://pypi.python.org/pypi/atpublic
* License : ASL2
  Programming Lang: Python
  Description : @public decorator for adding names to __all__

I plan to maintain this package within the DPMT, although I will be
the Maintainer and DPMT will be in Uploaders.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJXPHgEAAoJEBJutWOnSwa/ATAQAIv3xL2OvPQopDY5aLqQ1+hL
Fwr43Rcr/MfSWUariNBBYaSi49TAEvuiWyjYBA/igoGjwcO9H18gDzBU0d53KADQ
R+ifn2wQAFY+EPFEyIoSTLqFXnqkRALefM5KVkUZoOB1n6O6SQz7vkWqTqq0gpxm
wGS57qu+CAHluQep5wjS10Aca6NWc0MTg+kneqIrThbSMZYAo/QkTeiEADeCvJK2
eq+Jug0AJc9vvTVDfq+WqcOzVnZ/vDkXjDDazdk+GC2jZHSdI8sIPYZGoll0OLIK
ZlhYGufjlKLgt4iguFaqMDgrk7wpCohtMiqQ5HMjC5lSRPDPeBXTMkJKm9VHCBlJ
e4bLEYXcTjiCll/vpFx8CGSIvNlTDT4kb7JkFnrOPlEblocozOsCl2HYWWg1xNHk
sC/bEPeM6IhVJf7StesXaZRRI/oxZe8XqcRXwmMCfBF5Gjf5Riv9+9Ddwb2XigXw
9KkunjRyu7+v9Sgz7rRjk89VkOaE8syPoU0QXKZsYJ8k0wGM9t76ycjUjezog3Zl
iKJZnbTmk7nnCufhEkLbQ7b6QpGmnzwb61jX9xrY0yuN14l+nMWR5rTkqhClmLlb
9/CUqPbhldBoDxeP2ARJ56V/z45TxoaogidyV8/URiHhlyAIL3Pcn3n0+XPr4tTw
7OBQSp21mUdvqLzOuiOR
=GdOR
-END PGP SIGNATURE-

Bug#824566: (no subject)

[Barry Warsaw]

I don't know how to use targetcli.  I tried the simple command you gave in
your bug report, but that failed for other reasons (some kind of input file is
missing).

In any case, I just uploaded pyparsing 2.1.4+dfsg1-1 which has a number of bug
fixes.  Please try that.  If it works for you, great!  Please close this bug.

If it still doesn't work for you, please provide a reproducible test case.

Bug#817936: roger-router: Please add libpeas-1.0-0-python2loader to Depends

[Barry Warsaw]

On May 13, 2016, at 08:51 AM, Rolf Leggewie wrote:

>Ubuntu is still unchanged both in Xenial and Yakkety.

I'm currently in the process of resyncing the libpeas stack in Debian back to
Yakkety.  It's slow going because the python2/3 loader issue isn't the only
delta from Debian in these packages.

I'm not currently planning on SRUing all of this back into Xenial, and I'm not
even sure such SRUs would be acceptable.  Let's try to DTRT in Yakkety and
figure out the minimal amount of work needed to fix whatever's broken in
Xenial.  But let's do the latter in response to actual bug reports from users.

Since roger-router doesn't ship any Python code itself, I don't think it
should Depends on libpeas-1.0-python2loader.  Given that your follow up to
Jan-Michael asks about the existence of Python 2 plugins for roger, it seems
premature to add that Suggests to roger, and I totally agree about encouraging
the port of any such third party plugins to Python 3.

Note that any plugins which exist in the archive should themselves Depend on
libpeas-1.0-python2loader if they are Python 2.  (For Xenial, they'd have to
add a Depends on libpeas-1.0-python3loader if they were Python 3, but for
Debian and Yakkety, they would just Depends on libpeas since they get the
Python 3 loader for free now.)  Any third-party plugins not in the archive
will have to apt install the Python 2 loader itself.

Does that sound right and good to you?


pgp7EwnpJGPH4.pgp
Description: OpenPGP digital signature

Bug#824072: TypeError: unsupported operand type(s) for +: 'NoneType' and 'str'

[Barry Warsaw]

Package: pyflakes
Version: 1.2.2-1
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear Maintainer,

Reported over on Launchpad at:

https://bugs.launchpad.net/pyflakes/+bug/1560134

Filing here since I plan on fixing it in Debian.  Reproduced by:

$ echo "from . import foo" > foo.py
$ pyflakes foo.py
$ pyflakes3 foo.py


- -- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.5.0-2-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages pyflakes depends on:
ii  python-pyflakes  1.2.2-1
pn  python:any   

Versions of packages pyflakes recommends:
ii  pyflakes3  1.2.2-1

pyflakes suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJXM58FAAoJEBJutWOnSwa/IGQP/0sXKlNRbXedT8YnENzd9fOc
ukaBUT0DITu5nV+60ZnKrnUIWXEI5QQgMum0MLZBKVj1d5o6S1PvwY4zyerhNvsz
MCkovP2Jz4UMI5It/GY72ZeCC7irxe/3KijXyK8rH3zsrp0sL1/A8E7kLKAoD2Ni
B+YFAMybjSDYLCWr78p2/UMbdz6eG7LRPBMC2H3JDhbydK6cfgooSkGiFT/BX+AX
nR/VRVSA599IsCjITrMsmSiegAXPNsd8lb+JTipin7WW/6sedxa6FQhKdifg3ytw
VlcASQzKLONePw9NxdPHDc33AopAETxNuu8J/zgKl9fSZs/4227QQI8In5inNdOu
In6q7uF6Pp4991Ev0KXAo7wwGqwYhEgFxzpxN4kdJ3/cAVVnh6CHDfk4mOiI8FSu
Cttz7pxlD65QpNPvdw7j027d3ce7xfTIQyFH8TJ7sz7eDr5A8XBu7S5bcmWap0ac
SCRXGlZpLsQOEE9RR9LlQ8PY4UGZKt6U9yu4mn6y8QfOfB8wAHTnLr7K3GIrn+ja
sKMPfPH1kT964gxJgg/lDc4UBTFsGsuOYxtsTdVrWTLzeFLZXmHNZ/XtftWTnw9J
uQscumXo59myUAxKlwps8SjkXjggjJP8Q9+OoR5lowbcDlo34ippLL6tB2V1NHzX
qBNkxmKiBab9FbgmrE/P
=zu+M
-END PGP SIGNATURE-

Bug#823883: (no subject)

[Barry Warsaw]

On May 11, 2016, at 10:25 AM, Antonio Terceiro wrote:

>this test is indistinguishable from one that tests for python2 only ...
>only now I noted that all of the python tests are inherentily flawed as
>they are testing whether print is called with or without parenthesis,
>instead of checking for what really matters, which is what interpreter
>was actually called.
>
>I fixed that in
>http://anonscm.debian.org/cgit/collab-maint/autodep8.git/commit/?id=33d660c
>
>would you mind rebasing your patch on top of the current master and
>testing again?

Done!  I also fleshed out a few other tests related to PyPy support.
Hopefully I did them correctly. ;)

Thanks again.  pypy branch updated.




pgpsFhqOFA4CY.pgp
Description: OpenPGP digital signature

Bug#823931: autodep8: Append to existing tests

[Barry Warsaw]

On May 11, 2016, at 10:29 AM, Antonio Terceiro wrote:

>well if debian/tests/control already exists adt-run will not call
>autodep8 at all.
>
>what we could do is make so that if debian/tests/control.autodep8.in (or
>something similar) exists, autodep8 begins its output with the contents
>of that file, and appends whhat it would normally produce.
>
>But note that in specific case of the current Python support, if your
>manually specified tests do anything useful all against the package, no
>matter how small, that already renders the simple import test pointless.

If the simple import test runs against all available Python versions (in
practice, that will be only Python 3) then it might still be worth it, as any
additional tests may e.g. only run against 'python3' i.e. the default Python 3
version.  Import tests against all Python 3 versions might be useful during
transitions.

But I get your point.

If it's still worth doing, then I like your suggestion in the second paragraph
above.


pgpIfZUqTmOFQ.pgp
Description: OpenPGP digital signature

Bug#823931: autodep8: Append to existing tests

[Barry Warsaw]

Package: autodep8
Version: 0.5.1
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear Maintainer,

autodep8 is very cool.  I'm not sure whether this is within its
mission but it would be kind of nice if it could run in append mode so
that if you had existing tests that flexed a package more than, e.g.
for Python, doing an import test, the existing tests could be
augmented by the autodep8 generated tests.


- -- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.5.0-2-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages autodep8 depends on:
ii  dctrl-tools  2.24-2
ii  python3  3.5.1-3

autodep8 recommends no packages.

autodep8 suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJXMfXPAAoJEBJutWOnSwa/WUgQALev1TvLwLIABfRXCeXsnb4c
ZoJRZ2W3dPLJV3oXagz1tAO1XYh8DBBXD89nM448G3ZTpXpcwWcn468eMn5bDhez
GJh06A/p/8XnvOiDa/zg/1oqL6NTA/YSoUAE5ejFtp/Ncl758lXw+6rfJlhXc6OO
WLyQpchZbMl9pAXqc3/UEd2HAWAAuFcYPQ1phdp2/9gM7jS8aWKKN+/PipYcN9Yc
zAu/eCl2W3tc5DRquxAPrNsSo63zJn+8MUvBR3OJi3wR+aAMj/zDQOeWCUvMXQnG
Yt7A87JlYT4lesWrzm4M0cVX7Lvtl544N81uw7f8mVulAYA6RutZzAI8TDlD8WEM
VBQ8vawcqP8qTxBkqKwqV0BBNdnWBTDJ28ZRqe20We3UU5IzxeHHYnWTmHA7u0se
O7+QGemUOrNjTiTqZb+1GOCDOhA5giJQ09ZhBpvH7oapsSYLotDt3oDLKrjS9byM
DSG9jHMPF5tbIHc+1daN2FqjZ+Z4NVpFcqx3h/mICPpOsQAgj4SDZsmFXMlBmTd7
yF5ydGh9F5IbFXrVF8WWnP2q4YwwyH3ybay2OfAPOkvjY3rZLU/yCkwNy6yRF7kh
x2w/O6o7WYz0FMrkWQOsbWsO5dTC0H8Bwa0uBNTomtsZJko8+jWJhXC5xbBhDwcg
uG25As29ZyjYVfhfhCD5
=lh3v
-END PGP SIGNATURE-

Bug#823883: (no subject)

[Barry Warsaw]

Looks like I could, so I did!

I pushed a 'pypy' branch to git which, if not perfect, seems to work for me in
some limited testing without breaking the existing test suite.  I'll attach a
diff here for the fun of it.
diff --git a/support/python/detect b/support/python/detect
index 31e23be..4e4e528 100755
--- a/support/python/detect
+++ b/support/python/detect
@@ -1,4 +1,5 @@
 #!/bin/sh
 
 grep-dctrl --quiet -F Source -r '^python3\?-.*$' debian/control || \
-  grep-dctrl --quiet -F Package -r '^python3\?-.*$' debian/control
+  grep-dctrl --quiet -F Package -r '^python3\?-.*$' debian/control || \
+grep-dctrl --quiet -F Package -r '^pypy-.*$' debian/control
diff --git a/support/python/generate b/support/python/generate
index b6fd61c..96e1966 100755
--- a/support/python/generate
+++ b/support/python/generate
@@ -3,6 +3,7 @@
 module=
 py2_package=
 py3_package=
+pypy_package=
 
 # Try source package
 source_package=$(grep-dctrl -n -s Source -F Source -r '^python3\?-.*$' debian/control || true)
@@ -12,6 +13,12 @@ if [ -n "$source_package" ] ; then
 py3_package=python3-$module
 fi
 
+source_package=$(grep-dctrl -n -s Source -F Source -r '^pypy-.*$' debian/control || true)
+if [ -n "$source_package" ] ; then
+module=${source_package#python-}
+pypy_package=pypy-$module
+fi
+
 # Try binary package(s)
 if [ -z "$source_package" ] ; then
 binary_packages=$(grep-dctrl -n -s Package -F Package -r '^python3\?-.*$' debian/control || true)
@@ -31,6 +38,24 @@ if [ -z "$source_package" ] ; then
 fi
 fi
 
+# Try binary package(s)
+if [ -z "$source_package" ] ; then
+binary_packages=$(grep-dctrl -n -s Package -F Package -r '^pypy-.*$' debian/control || true)
+if [ -n "$binary_packages" ] ; then
+for binary_package in $binary_packages ; do
+module=${binary_package#*-}
+case $module in
+*-doc|*-dbg|*-dbgsym|*-dev)
+continue
+;;
+esac
+
+pypy_package=pypy-$module
+break
+done
+fi
+fi
+
 # Python2
 if [ -n "$py2_package" ]; then
 if [ "$(grep-dctrl -n -s Package -F Package -X "$py2_package" debian/control)" ] ; then
@@ -52,3 +77,14 @@ Depends: $py3_package
 EOF
 fi
 fi
+
+# PyPy
+if [ -n "$pypy_package" ]; then
+if [ $(grep-dctrl -n -s Package -F Package -X "$pypy_package" debian/control) ] ; then
+cat <

Bug#823922: pyparsing: Update debian/copyright

[Barry Warsaw]

Source: pyparsing
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear Maintainer,

- From ftpmaster:

Please can you update debian/copyright to reflect (at least) the files
under examples/ on the next upload. Thanks.


- -- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.5.0-2-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJXMd6GAAoJEBJutWOnSwa/Rm8QAI69bYJYtv5sTx5uk80za71z
sCzzjEqzzDCXJhQikuIV58jPdsSkXWZhNvLDfamZKH6Z0fwGkTkJNFGwXT/bAopQ
34/A89FIF+Tspc+Q8bDfYY227fpDVXDlNIjiKTRtPgcXmG+H1W36QAK9vSZlYFeo
CHXAOJwnWqP4LTqapE4x92PX0JPy+lXErsAminNI91nKFIsjvxhZs0icc9dXxNQL
RHx0eK6wkvIuLK8jCuRLbhu22lE3Hefdod7LU63/m78b3ufkiHgnHMxcYtC1ZRuD
HSWibTq67hZzHjm6LZ9yuxmP8Q7J+M0by7VDR3Ibi+FbDWchBozRPbr5H3KECjHm
H0gWwQr2iI6hjhtC6IcmGqozrmPsLT/wZ69H0JC01B1jBmnT+amLrKE+Y9vsrAQ2
OfFwQ+dQ9Wx6tYoob+FNltBB8ziEzENyHIbSn3vs2ViBAR6wmdkPe69k3E/DldNl
ovBLwCQ6E97yrWOZHVNi4vbf0rRl3MmxvG7qa16auraB74hW5bvI4EgELLKLTzNO
1plZKb1qjUGaKRkoGyBFYwB34a8zdIW7qSKD/l8di534S0oap0mkEgz5QOY714X9
NZHYG114NDSagIROdMBk7SF4pzHozMsgfD7JfyzzvNXcKFc28YNXWOVWsZ+GZGSq
DX9sFSl6VU9pvzKqraCU
=uBHz
-END PGP SIGNATURE-

Bug#823883: autodep8: Support PyPy packages

[Barry Warsaw]

Package: autodep8
Version: 0.5.1
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear Maintainer,

Currently autodep8 does a great job of adding simple import tests for
Python 2 and Python 3 packages.  It doesn't yet support PyPy though,
and as we add more support for PyPy in the archive, it would be nice
to get PyPy tests for free too.

- -- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.5.0-2-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages autodep8 depends on:
ii  dctrl-tools  2.24-2
ii  python3  3.5.1-3

autodep8 recommends no packages.

autodep8 suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJXMSfFAAoJEBJutWOnSwa/ojIQALXBcswEuxWRRKo8KWv/8QUu
0x6EXLxOVNhd+u2km+8YGaQx3rB8wcg1mKpEWVfmncNHVXp3VTW0GkcLzTi0CFHV
rqDXiFeMjbcO9xOxfGoVVMZMB1tYRlPNahv58yc/ePYuaouWamxj3CeQ/KiW6fZU
h81galucUL7/1pkLXpkum3nQx/7D5X51J5MK35sF8XylP3+ozpIH7VuklA5Whu52
Jcxgos121XN1zuP93ZMgiGCjjpXIl9UdBnK30n0CNWtQgbcKwcgrOt/KXUddLn5Q
5NuH0dJc7Fd8oO3O9T2D4dyHSXCtbCllLXqyvOGovi3acNZuLB1GfNRrCop1ZiWd
bGWTbp8GnV/kRoYW+hYnzJI/2LlJi/qtRwboJcu9DipBQgQDu1bCf0tUPfzMzRhX
iaFCX+O20mcE71V1hhIYImpboQrtydxkurO+yuwdbAHda3alsK95CvABDtRPO14f
FR5ebMBJh2RDgLr6IECA6Y1/Gku8ndGezh34lqnNGxZ+b4cO4USZJ4GaJVEmdql8
wwNXJL/qdIsvxsz0Aoyeog4lC1brfnBWI7CSlzAGiY+O6Mhz1Lvp9RvolByVLlcI
1fTtxwd4PD5Nu6OTV4tiAAw7zl8Rz9fEVczHIhnNz8ZtduISWYPoksnu+VlSSPBa
w3xWFcS8MTpaIgJL8/Cr
=8DFJ
-END PGP SIGNATURE-

Bug#823628: lintian: Please add autopkgtest-pkg-python to known test suites

[Barry Warsaw]

On May 06, 2016, at 10:05 PM, Axel Beckert wrote:

>Lintian in git already knows about this (for about a week :-), hence
>marking as pending.

Yay!  Thanks.


pgpUkehrL8JoF.pgp
Description: OpenPGP digital signature

Bug#823628: lintian: Please add autopkgtest-pkg-python to known test suites

[Barry Warsaw]

Package: lintian
Version: 2.5.44
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear Maintainer,

In Python packages, with autopkg8, you can now say this in your
d/control file:

Testsuite: autopkgtest-pkg-python

but lintian doesn't know about this yet:

Now running lintian...
W: pyparsing source: unknown-testsuite autopkgtest-pkg-python
Finished running lintian.

- -- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.5.0-2-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages lintian depends on:
ii  binutils  2.26-8
ii  bzip2 1.0.6-8
ii  diffstat  1.61-1
ii  file  1:5.25-2
ii  gettext   0.19.7-2
ii  hardening-includes2.8+nmu2
ii  intltool-debian   0.35.0+20060710.4
ii  libapt-pkg-perl   0.1.29+b5
ii  libarchive-zip-perl   1.57-1
ii  libclass-accessor-perl0.34-1
ii  libclone-perl 0.38-1+b1
ii  libdata-alias-perl1.20-1+b1
ii  libdpkg-perl  1.18.6
ii  libemail-valid-perl   1.198-1
ii  libfile-basedir-perl  0.07-1
ii  libipc-run-perl   0.94-1
ii  liblist-moreutils-perl0.413-1+b1
ii  libparse-debianchangelog-perl 1.2.0-8
ii  libperl5.22 [libdigest-sha-perl]  5.22.2-1
ii  libtext-levenshtein-perl  0.13-1
ii  libtimedate-perl  2.3000-2
ii  liburi-perl   1.71-1
ii  libyaml-libyaml-perl  0.41-6+b1
ii  man-db2.7.5-1
ii  patchutils0.3.4-1
ii  perl  5.22.2-1
ii  t1utils   1.39-2
ii  xz-utils  5.1.1alpha+20120614-2.1

Versions of packages lintian recommends:
ii  dpkg 1.18.6
ii  libautodie-perl  2.29-2
ii  libperlio-gzip-perl  0.19-1+b1
ii  perl 5.22.2-1
ii  perl-modules-5.22 [libautodie-perl]  5.22.2-1

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  dpkg-dev   1.18.6
ii  libhtml-parser-perl3.72-1
ii  libtext-template-perl  1.46-1

- -- no debconf information

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJXLPYlAAoJEBJutWOnSwa/VwYP/0X+AAKxdoVBCThnsrRnViX6
iJQxQeFaL2pONTOHROVhUm+SfKlmKPePjSkmhSrHQDNTeDtfOy13Q7CE+xV5TXgq
YKhrrBqlte97QLNgQCX0gri7qcsvbqrglrIRI+rcYh7VDllGWUkkkVjAth0wqJqx
/+s+A1chMT6b1s5z1GKK+yVZVs8lj4quNObI4peSn3LCEtvEd4wOPYwJaO/ULrN9
a13r08PDN0R0icyz2kB0j9HF7OMXs9nXTWO1R961xJZUB9oUl+Y81+FyE4he/9LW
zQumW32j9v2G+B0BIPGZaF7agYuryQEUnj20MuhIYJoyybomzBMEmMofS0KGJ40j
iShDknUlA7Ol8c1+texZhT7gTwI948zirLy8puHCe6RXx9gq+Fean5mvl/lihkWV
/O7i8ufMQP4UctHJeNAOUUKtSaVQDc7FoKyKL4BtNWJILLQ733paniEuvRhfDAuu
aKsjf6ddAKzJDHS233MEI2Ui3z5hqxf6k3I8KRxR+CxROEOefjLs/UtRTKtldjOp
m7TixrPlfmpp2Pvc+AOapwRN+ChKXH+Nuo0ko6KGqZv1rFBw2uT4pTzAnjR6B0Zc
TEMgPHaFPliiGscBrxFxehJ5gaXSYnd99Dlw1bbNEmwBT3FlJBS8ClQtYV6xmx/6
VyTiC1NrSKarq2vgg9Yn
=T8TY
-END PGP SIGNATURE-

Bug#822750: (no subject)

[Barry Warsaw]

Exactly what command did you run?

I can't reproduce this:

% pip install world
Collecting world
  Using cached world-3.1.1-py2.py3-none-any.whl
Collecting setuptools (from world)
  Using cached setuptools-20.10.1-py2.py3-none-any.whl
Installing collected packages: setuptools, world
Successfully installed setuptools-20.10.1 world-3.1.1

% pip --version
pip 8.1.1 from /usr/lib/python2.7/dist-packages (python 2.7)

% dpkg-query -W python-pip
python-pip  8.1.1-2

Bug#821442: schroot: operation not permitted (only with 4.5 kernel)

[Barry Warsaw]

On Apr 18, 2016, at 09:40 PM, James McCoy wrote:

>I've been seeing something similar.  Am I right to assume that these are
>union-type=overlay?  If so, this seems to be a change in the kernel.

Yep, union-type=overlay.


pgpyRCcXhRcjK.pgp
Description: OpenPGP digital signature

Bug#821442: schroot: operation not permitted

[Barry Warsaw]

Package: schroot
Version: 1.6.10-2
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear Maintainer,

With today's dist-upgrade, I am unable to enter an existing or newly
created chroot, nor am I able to sbuild or adt-run with the chroot.

I had an existing sid-amd64 chroot which I could not enter.  I then
removed the chroot and recreated it with mk-sbuild.  Now I get:

% schroot -u root -c sid-amd64
E: 15binfmt: update-binfmts: unable to open
/var/run/schroot/mount/sid-amd64-98db94f4-3bc6-4948-95a6-57a8e986bba9/bin/sh:
Operation not permitted
E: 20copyfiles: cp: cannot create regular file
'/var/run/schroot/mount/sid-amd64-98db94f4-3bc6-4948-95a6-57a8e986bba9/etc/resolv.conf':
Operation not permitted
E: 15binfmt: update-binfmts: unable to open
/var/run/schroot/mount/sid-amd64-98db94f4-3bc6-4948-95a6-57a8e986bba9/bin/sh:
Operation not permitted
E: sid-amd64-98db94f4-3bc6-4948-95a6-57a8e986bba9: Chroot setup
failed: stage=setup-start

sbuild and schroot are completely unusable for me now.


- -- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.5.0-1-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages schroot depends on:
ii  libboost-filesystem1.58.0   1.58.0+dfsg-5+b1
ii  libboost-iostreams1.58.01.58.0+dfsg-5+b1
ii  libboost-program-options1.58.0  1.58.0+dfsg-5+b1
ii  libboost-system1.58.0   1.58.0+dfsg-5+b1
ii  libc6   2.22-6
ii  libgcc1 1:5.3.1-14
ii  libpam0g1.1.8-3.2
ii  libstdc++6  5.3.1-14
ii  libuuid12.28-1
ii  schroot-common  1.6.10-2

schroot recommends no packages.

Versions of packages schroot suggests:
ii  aufs-tools1:3.2+20130722-1.1
pn  btrfs-tools   
ii  debootstrap   1.0.80
pn  lvm2  
pn  qemu-user-static  
ii  unionfs-fuse  1.0-1

- -- Configuration Files:
/etc/schroot/default/fstab changed [not included]

- -- no debconf information

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJXFSQfAAoJEBJutWOnSwa/d8IP/RQX/qgVYI6m9MXHhZ3v0S5f
qTIguYTnCjQhUie0EibPufPtAYLUW97cSMfDV3HUhazf2KBUu1IjtqfoAn5GuT5f
1HvQKK+3kcpemQXRVbNap2lVdROeW6XlweAfn+aXk5i+1UOLcQzT80mNNnlb7grI
hRkncz2lp/A5Imy6Y99/oCb36EHIWcZzFaL9D7paIqOuT7+kb8KRKqZDphyDiwuz
YrWz8AxWC+3srEwVxX5Gzcijy3l7rWVONhcEmf2J/lz8HsCQC7BRfeiMrNzweVq9
bRqNGibSSjx0OWkkKhXpQtKGrXMD8NFGbb0O7CaICfK0OsKvbvKd6GrmIrgZB1FW
rgL9/TFxA/+3DfGRQrBKmyRjRy34z1/bGM54YNaCoHBTBX8R3FlMDAc3iyhhLryq
1HuB4krISf/kdtQAhpKgJDiPr9xxkma/7eQQHozWynzNSeesu/BSd9ufyNTIKUkT
0fFojkxYAe3BxfPlhXAwr6vNOvx06WJ4gj/CNvZwFKhEBTbtGsRBpz01o1i0hld/
db7JqG3lUAx6ukRYjfuH0rFfMo2XPPc9uAqgnWpJj+Gm+ucSBU9vl8A3rcV1AFsV
vKyojKYYF/+EsA0uAPp7OcQoUXJKMW2knN+bD5ZiKZvAYCfipdaofVbkUP5qYVh1
6a326uhBdOUovIeQx9mu
=jKzr
-END PGP SIGNATURE-

Bug#821223: [Python-modules-team] Bug#821223: Unable to create a virtualenv: invalid requirement: '_markerlib'

[Barry Warsaw]

I'll have a fix uploaded momentarily.

Bug#821223: (no subject)

[Barry Warsaw]

Can you please report the output of `dpkg-query -W python-pip-whl`, both if
virtualenv works and doesn't work for you?

Bug#814397: (no subject)

[Barry Warsaw]

We should devendor packaging from setuptools.  From IRC:

 By the way, I'm pretty sure that
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=814397 is because
  pip unbundles and the latest python-pkg-resources doesn't
 (now that I actually look at setuptools)
 so pip is using packaging.version.Version and pkg_resources is
  giving it pkg_resources._vendor.packaging.version.Version  [16:48]

Bug#820195: (no subject)

[Barry Warsaw]

FWIW, attached is the patch in Ubuntu which fixes the FTBFS.  This comes from
0.6-1ubuntu1.
Description: Adapt tests to changes in NumPy 1.10 Default casting rule
Origin: Upstream (commit 9b91b1789c8dc81e84c0a8691febbd1e242a81d1)

---
 pint/testsuite/helpers.py | 8 +++-
 pint/testsuite/test_issues.py | 2 +-
 pint/testsuite/test_numpy.py  | 1 +
 3 files changed, 9 insertions(+), 2 deletions(-)

--- a/pint/testsuite/helpers.py
+++ b/pint/testsuite/helpers.py
@@ -2,11 +2,17 @@
 
 from __future__ import division, unicode_literals, print_function, absolute_import
 
+from distutils.version import StrictVersion
+
 from pint.compat import unittest, HAS_NUMPY, HAS_UNCERTAINTIES, NUMPY_VER, PYTHON3
 
 
 def requires_numpy18():
-return unittest.skipUnless(NUMPY_VER >= '1.8', 'Requires NumPy >= 1.8')
+return unittest.skipUnless(StrictVersion(NUMPY_VER) >= StrictVersion('1.8'), 'Requires NumPy >= 1.8')
+
+
+def requires_numpy_previous_than(version):
+return unittest.skipUnless(StrictVersion(NUMPY_VER) < StrictVersion(version), 'Requires NumPy < %s' % version)
 
 
 def requires_numpy():
--- a/pint/testsuite/test_issues.py
+++ b/pint/testsuite/test_issues.py
@@ -404,7 +404,7 @@
 self.assertQuantityAlmostEqual(x + y, 5.1 * ureg.meter)
 self.assertQuantityAlmostEqual(z, 5.1 * ureg.meter)
 
-
+@helpers.requires_numpy_previous_than('1.10')
 def test_issue94(self):
 ureg = UnitRegistry()
 v1 = np.array([5, 5]) * ureg.meter
--- a/pint/testsuite/test_numpy.py
+++ b/pint/testsuite/test_numpy.py
@@ -165,6 +165,7 @@
 self.assertRaises(ValueError, self.q.cumprod)
 self.assertQuantityEqual((self.q / self.ureg.m).cumprod(), [1, 2, 6, 24])
 
+@helpers.requires_numpy_previous_than('1.10')
 def test_integer_div(self):
 a = [1] * self.ureg.m
 b = [2] * self.ureg.m

Bug#820693: gdebi: Add flakes8 Build-Depends to fix FTBFS

[Barry Warsaw]

Package: gdebi
Version: 0.9.5.7
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear Maintainer,

pyflakes has been split with /usr/bin scripts in separate binary
packages for Python 2 and 3.  This causes gdebi to FTBFS because it
can't find pyflakes3.  A simple addition of pyflakes3 to Build-Depends
will fix the problem.

- -- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.4.0-1-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gdebi depends on:
ii  gdebi-core0.9.5.7
ii  gir1.2-gtk-3.03.18.9-1
ii  gir1.2-vte-2.91   0.44.0-1
ii  gksu  2.0.2-9
ii  gnome-icon-theme  3.12.0-1
ii  python3-gi3.18.2-2+b1
pn  python3:any   

Versions of packages gdebi recommends:
ii  libgtk2-perl  2:1.2498-1
ii  lintian   2.5.43
ii  shared-mime-info  1.5-2

gdebi suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJXC6bWAAoJEBJutWOnSwa/ywsQAKvowRpvQSl487SAPF56T2Cp
O4H+8LTeI3WUHN1LFyDLUCt/JJrKqC4+hkGQhtMmwhXbdNmefCQVFkMhRpWZp9lQ
2ulm6UWZs9SxHxxGYzemCo4zS5TnWMonbeBYiO9pddTkur/7G/F8L0joRGYcxN6z
7vbdPKPrN48wbH8HWFDBst4SV5OuEBvnOyhpdyOEFJ9yQLD84ufsArYLSfarkaYc
kdDerD0WR0E042u8P8WgxaJY3dT668ZBQqF28mdnCP/Ym9p+h43pvuXmN1qm6s1z
Uh8KGmx8FLxGzStEyrgd5cW628zYI/sM7ZROQe2nLTl/79VPBRaTqQbDeLQp43Sc
o5jV+3bngeJ6pqak1oWx91yD/e/q40nZODn32TVNcWVvW+WwfAOjfUbneL7BaxKY
uArSauKiiSgbBjUXlFGyAMPzWn085VgRLtfgcwtRVq8qPozMiLtTVPU1My64xTS/
3ZccAMaMYpLKZ8+dfUTMLKDcd4QauajifiaEraL0GUiweUJhtj/SUBWtGmHFaY2C
o8tAmXpogKhLri//GqxIzuNiZVsJTtuFWcnOKwDiVK+YN7e97NBeCKHWusmT0RRe
yZfnrBxKAQRTWtfKuYoJq+b/arg+N6YrE0N2Ogz/rXFQQThfbeoVKBzNkw87DgwB
E3vCtKArWB7OvNH88EfM
=uCXP
-END PGP SIGNATURE-

Bug#804582: (no subject)

[Barry Warsaw]

Okay, so I think the locale changes are enough to fix the FTBFS.  I retried
building in an Ubuntu PPA and the build succeeded.

The timeout failure must just have been a problem with my local sbuild.

Bug#804582: (no subject)

[Barry Warsaw]

It's a locale problem.  This fixes most of the problems:

diff --git a/debian/rules b/debian/rules
index 9c04662..6130dc4 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1,6 +1,8 @@
 #!/usr/bin/make -f
 
 export PYBUILD_NAME=paramiko
+export PYBUILD_VERBOSE=1
+export DH_VERBOSE=1
 
 %:
dh $@ --with python2,python3 --buildsystem=pybuild
@@ -11,3 +13,12 @@ ifeq (,$(findstring nodocs, $(DEB_BUILD_OPTIONS)))
 endif
dh_installdocs
 
+override_dh_auto_test:
+   mkdir -p $(CURDIR)/tmp-locales
+   localedef -i /usr/share/i18n/locales/en_US -c -f UTF-8 \
+ -A /usr/share/locale/locale.alias \
+ $(CURDIR)/tmp-locales/en_US.UTF-8
+   LOCPATH=$(CURDIR)/tmp-locales LC_ALL=en_US.UTF-8 \
+   dh_auto_test -- \
+   --system=custom \
+   --test-args='{interpreter} $(CURDIR)/test.py --verbose'


Unfortunately, I still have one last test I'm tracking down in python3.5
(python2.7 passes now):

==
FAIL: test_L_handshake_timeout (tests.test_transport.TransportTest)
--
Traceback (most recent call last):
  File "/<>/tests/test_transport.py", line 811, in 
test_L_handshake_timeout
password='pygmalion')
AssertionError: EOFError not raised by connect

Bug#804582: (no subject)

[Barry Warsaw]

I haven't quite fixed it yet, but it's almost certainly related to FOLDER in
test_sftp.py.  When the tests, such as test_K_utf8() fail, it's because the
folder isn't empty so the os.rmdir() fails.

Quickly I tried to add a TEST_FOLDER=`mktemp -d` to the test command but that
didn't quite work.  I think that's still probably on the right track, but I
don't have some detail right yet.

Bug#804582: (no subject)

[Barry Warsaw]

On Apr 08, 2016, at 10:59 AM, Jeremy T. Bouse wrote:

>Yes, I'd taken a slightly different approach but got to the same results
>that you are currently getting. I have included your approach as it is
>much cleaner than what I'd hacked together.
>
>Still trying to get to the bottom of those remaining failures causing
>the test to fail and the build to cease.

Awesome, thanks.  I'm also trying to investigate those last few failures.  I
applied the following patch to get a bit more debugging, but other than seeing
the errno is 4 (EINTR) I don't have any more information.

I also looked at updating the package to the latest upstream but that didn't
seem to help the failures, and upstream's latest tarball isn't compatible with
the current quilt patch.  I also tried 1.15.4 but that didn't help either.

I'll also note that `tox -e py27,py35` of upstream's git (master, v1.15.3, and
v1.15.4) passes all its tests so there's something weird about the build
environment that's breaking the build.  FWIW, I'm using sbuild with a sid
chroot.

--- a/paramiko/sftp_client.py
+++ b/paramiko/sftp_client.py
@@ -803,7 +803,7 @@
 elif code == SFTP_PERMISSION_DENIED:
 raise IOError(errno.EACCES, text)
 else:
-raise IOError(text)
+raise IOError(code, text)
 
 def _adjust_cwd(self, path):
 """


pgp6nN2GYGMTB.pgp
Description: OpenPGP digital signature

Bug#804582: (no subject)

[Barry Warsaw]

I'm running across this too now.  I think part of the problem is that pybuild
invokes unittest discover by default, but this isn't how paramiko's test suite
is actually run, at least if you go by what's in the tox.ini file.

This gets me closer:

diff --git a/debian/rules b/debian/rules
index 9c04662..8d5d25b 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1,6 +1,7 @@
 #!/usr/bin/make -f
 
 export PYBUILD_NAME=paramiko
+export PYBUILD_TEST_ARGS={interpreter} $(CURDIR)/test.py
 
 %:
dh $@ --with python2,python3 --buildsystem=pybuild
@@ -11,3 +12,5 @@ ifeq (,$(findstring nodocs, $(DEB_BUILD_OPTIONS)))
 endif
dh_installdocs
 
+override_dh_auto_test:
+   PYBUILD_SYSTEM=custom dh_auto_test


But I'm still seeing two failures and two errors:

==
ERROR: test_K_utf8 (tests.test_sftp.SFTPTest)
--
Traceback (most recent call last):
  File "/<>/tests/test_sftp.py", line 171, in tearDown
sftp.rmdir(FOLDER)
  File "/<>/paramiko/sftp_client.py", line 390, in rmdir
self._request(CMD_RMDIR, path)
  File "/<>/paramiko/sftp_client.py", line 729, in _request
return self._read_response(num)
  File "/<>/paramiko/sftp_client.py", line 776, in _read_response
self._convert_status(msg)
  File "/<>/paramiko/sftp_client.py", line 806, in _convert_status
raise IOError(text)
IOError: Failure

==
ERROR: test_L_utf8_chdir (tests.test_sftp.SFTPTest)
--
Traceback (most recent call last):
  File "/<>/tests/test_sftp.py", line 679, in test_L_utf8_chdir
sftp.mkdir(FOLDER + '/' + unicode_folder)
  File "/<>/paramiko/sftp_client.py", line 380, in mkdir
self._request(CMD_MKDIR, path, attr)
  File "/<>/paramiko/sftp_client.py", line 729, in _request
return self._read_response(num)
  File "/<>/paramiko/sftp_client.py", line 776, in _read_response
self._convert_status(msg)
  File "/<>/paramiko/sftp_client.py", line 806, in _convert_status
raise IOError(text)
IOError: Failure

==
FAIL: test_K_utf8 (tests.test_sftp.SFTPTest)
--
Traceback (most recent call last):
  File "/<>/tests/test_sftp.py", line 675, in test_K_utf8
self.fail('exception ' + str(e))
AssertionError: exception Failure

==
FAIL: test_O_getcwd (tests.test_sftp.SFTPTest)
--
Traceback (most recent call last):
  File "/<>/tests/test_sftp.py", line 734, in test_O_getcwd
self.assertEqual(None, sftp.getcwd())
AssertionError: None != u'/'

--
Ran 148 tests in 34.596s

FAILED (failures=2, errors=2)

Bug#807351: (no subject)

[Barry Warsaw]

I just ran across this bug too, but not until I worked out a different
patch. ;)

I'd be fine with Neil's patch, or deleting the test entirely.  In the
attached, I only assert that the SystemError is raised, but not what the
exception message is.

The other change is to close a small (possibly only theoretical) hole which
could leak the temporary file.  Ideally, this should probably use a
with-statement and tempfile.NamedTemporaryFile.
diff --git a/tests/test_deb822.py b/tests/test_deb822.py
index 698366b..33c569d 100755
--- a/tests/test_deb822.py
+++ b/tests/test_deb822.py
@@ -911,16 +911,17 @@ Description: python modules to work with Debian-related data formats
 
 See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=750247#35
 """
-fd, filename = tempfile.mkstemp()
-fp = os.fdopen(fd, 'wb')
-fp.write(UNPARSED_PARAGRAPHS_WITH_COMMENTS.encode('utf-8'))
-fp.close()
-
 try:
+fd, filename = tempfile.mkstemp()
+fp = os.fdopen(fd, 'wb')
+fp.write(UNPARSED_PARAGRAPHS_WITH_COMMENTS.encode('utf-8'))
+fp.close()
+
 with open_utf8(filename) as fh:
-paragraphs = list(deb822.Deb822.iter_paragraphs(
-fh, use_apt_pkg=True))
-self.assertEqual(paragraphs[0]['Build-Depends'], 'debhelper,')
+self.assertRaises(SystemError,
+  list,
+  deb822.Deb822.iter_paragraphs(
+  fh, use_apt_pkg=True))
 finally:
 os.remove(filename)
 

Bug#806824: libpeas python split

[Barry Warsaw]

Hi Michael,

On Apr 04, 2016, at 01:52 AM, Michael Biebl wrote:

>Andreas was suggesting a compromise.  Split out the python2 loader but keep
>the python3 loader within the main libpeas-1.0-0 package. This will reduce
>the churn quite a but.

I think I missed that, thanks for the clarification.

This solution works for me.  I'll note the one difference is that it will keep
a Python dependency even for libpeas clients that don't extend through Python
(crazy talk, I know! :).  But since it will be a Python *3* dependency and
Python 2 can be split off and demoted, that's okay by me.

>This means we can close most of the bugs and and only need to keep the 3
>python2 bugs open. We should follow up there and make it clear that they
>should update to python3. They then can drop the explicit dependency on
>the python2 loader package again.

+1

>I intend to work on the libpeas package the next couple of days.
>One of the modfications I'd like to do, is move the python2 loader
>package to oldlibs/extra and drop the soname specific part from the package.
>
>I hope you can agree with this plan, if not, please shout.

 I agree with the plan.  :)

Thanks!


pgpp8atBQIAEo.pgp
Description: OpenPGP digital signature

Bug#817936: roger-router: Please add libpeas-1.0-0-python2loader to Depends

[Barry Warsaw]

On Apr 02, 2016, at 10:33 PM, Rolf Leggewie wrote:

Hi Rolf,

>I'm still at a loss what it is you are asking of me.  The title of this
>bug requests me to add a run-time dependency that doesn't even exist in
>Debian yet.  In Ubuntu the change you advocate has been made, but
>apparently there were no changes necessary for roger-router alongside. 
>In fact, roger-router in Ubuntu still depends on libpeas-1.0.0 and not
>libpeas-1.0-0-python2loader even though the package does exist there.

We should certainly fix roger-router in Ubuntu; I'm not sure how I missed that
one over there.  I'll file a bug and fix that early next week.

>Should I be mistaken to think that this ticket is invalid?

It depends on how you look at it. :)  If I can convince the libpeas maintainer
to make the split, then roger-router in Debian will need to be fixed, hence
this bug would be valid.  But it doesn't seem like I'm going to be successful
in convincing the libpeas maintainer about the split, so there's certainly
nothing for you to do now.  Of course, we can always reopen this bug later if
the libpeas maintainer agrees with the change.

I look at this as a tracking bug - something that needs to happen if another
bug gets resolved, but nothing to do right now.  Thanks for your response; if
you think it's best to close this as invalid, no problem.


pgpbj1kmB7tim.pgp
Description: OpenPGP digital signature