Re: [Python-modules-team] Backports of flufl.i18n and flufl.lock to stretch-backports

[Barry Warsaw]

On Dec 23, 2017, at 10:26, Jonas Meurer  wrote:
> 
> we - the Debian Mailman3 maintainers - would like to backport the latest
> versions of flufl.i18n and flufl.lock from sid/testing to
> stretch-backports. They're required as dependencies for the Mailman3
> packages to be backported.
> 
> Do you have any objections? What's the prefered workflow? We would
> create a new branch 'stretch-backports' in the packaging repos for that.
> Is that ok or do you prefer any other workflow for backports to stretch?

Hi Jonas, et al.

I have no objections, and in fact I thank you for being so diligent and 
helpful.  As I am still on hiatus, DPMT is Debian Maintainer of both of these 
packages, so please just make sure DPMT git is up to date with whatever changes 
you make. Both packages are still on git-dpm, and I haven’t really been keeping 
up on the oft-discussed gbp-pqm conversion.  I’m happy for you to do whatever 
you and DPMT thinks makes the most sense.

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

Re: [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

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] 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-

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

Re: [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


pgpYSMy6g9X1C.pgp
Description: OpenPGP digital signature
___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

Re: [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.

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] 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?

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] 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.

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#837764: (no subject)

[Barry Warsaw]

Are you sure that link actually exists?

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

Re: [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.

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#754248: 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.


pgpd6xRk84j_A.pgp
Description: OpenPGP digital signature
___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] 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.

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] 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.

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] 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?

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#831271: (no subject)

[Barry Warsaw]

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

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] 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-

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

Re: [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.


pgpO9zWX9MtHM.pgp
Description: OpenPGP digital signature
___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] 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.

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

Re: [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.

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

Re: [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.

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

Re: [Python-modules-team] Removing me from Uploader field of html5lib

[Barry Warsaw]

On Jul 04, 2016, at 04:52 PM, Olivier Berger wrote:

>Unfortunately, I'm no longer able to dedicate time to help maintaining
>the html5lib package.

Thanks so much for your past work on it!

>Thus I'm requesting that anyone uploading the next version as part of
>the team, please remove me from the uploaders field.

Done in vcs.  If it's okay with you, I'll hold off doing a new upload until
there's a new upstream.

>Btw, the docs on the wiki documents how to be added/contribue, but not
>really how to stop ;-)

Despite that, you figured it out. :)

Cheers,
-Barry

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] 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.

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

Re: [Python-modules-team] [Python-modules-commits] [mpmath] 01/01: d/copyright: Changed licence shortname BSD -> BSD-3-clause

[Barry Warsaw]

On Apr 30, 2016, at 07:21 PM, Ondrej Novy wrote:

>announced before:
>http://lists.alioth.debian.org/pipermail/python-modules-team/2016-March/030256.html

Thanks!  I must have missed it, but you did the right thing.

-Barry

PS: why do we have two mailing lists?! :( :(


pgp3FKxlJshFs.pgp
Description: OpenPGP digital signature
___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

Re: [Python-modules-team] [Python-modules-commits] [mpmath] 01/01: d/copyright: Changed licence shortname BSD -> BSD-3-clause

[Barry Warsaw]

On Apr 30, 2016, at 04:10 PM, Sandro Tosi wrote:

>> I'm just going thru Lintian report and fixing few warnings.  
>
>but for this yes.

But why get pre-approval for *this* particular commit?  Which change do you
have a problem with?  I genuinely want to know because I do think we need to
have clear guidelines about what our teammates are allowed to work on.

A while ago, we did hash out the semantics of team in Maintainers vs
Uploaders.  Because commits are always reversible, I don't have any problem
with our current rules for team-in-Uploaders.  It's the compact we make by
having team maintained packages, and I for one think it's a good trade-off.  I
appreciate the help in cleaning up our collective packages.

>well, collaborative work kinda requires agreement on what that work
>would be, and also is not that collaborative to commit whatever you
>see fit and then let somebody else deal with it in a next upload. but
>hey "it's me"...

I think we should generally assume that our teammates know what they're doing
and have the skills and courtesy to follow the rules.  I recently noticed that
Ondrej committed some changes to fix our Vcs- urls to https, and I think that
was a nice thing to do!

For a mass change like this, Ondrej should have followed up with an email to
the list.  But he wasn't outside the bounds to make the change.

Cheers,
-Barry

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

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

[Barry Warsaw]

I'll have a fix uploaded momentarily.

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] 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?

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#817131: Bug#817131: Bug#817131: python-flake8: Missing binary

[Barry Warsaw]

On Mar 24, 2016, at 10:06 AM, Joel Cross wrote:

>Ddoes this mean that if I need to use the Python 2 version of Flake8 (for
>instance, for linting my Python 2 files), that I will need to install my own
>binary?  It seems to me that if the package is missing a binary, and that
>binary isn't provided by another package, then the package is pretty useless.

Ideally for these kinds of things, you would be able to run

$ python -m flake8 

or

$ python /usr/bin/flake8 http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#819037: (no subject)

[Barry Warsaw]

I just tried this on a fully dist-upgraded sid machine:

@chemistry[~:1005]% virtualenv -p python3.5 /tmp/p35
Running virtualenv with interpreter /usr/bin/python3.5
Using base prefix '/usr'
New python executable in /tmp/p35/bin/python3.5
Also creating executable in /tmp/p35/bin/python
Installing setuptools, pkg_resources, _markerlib, pip, wheel...done.
@chemistry[~:1006]% source /tmp/p35/bin/activate
(p35) @chemistry[~:1007]% pip install world
Collecting world
  Using cached world-3.1.1-py2.py3-none-any.whl
Requirement already satisfied (use --upgrade to upgrade): setuptools in 
/tmp/p35/lib/python3.5/site-packages (from world)
Installing collected packages: world
Successfully installed world-3.1.1
(p35) @chemistry[~:1008]% world it
it originates from ITALY
(p35) @chemistry[~:1009]% deactivate

Just a couple of days ago, Matthias uploaded a new version of Python 3.5 which
includes the fix for python3-venv, although I don't *think* that shouldn be
directly related to problems with pip inside virtualenv created venvs.

http://metadata.ftp-master.debian.org/changelogs/main/p/python3.5/python3.5_3.5.1-8_changelog

Still:

@chemistry[~:1012]% python3.5 -m venv /tmp/v
@chemistry[~:1013]% source /tmp/v/bin/activate
(v) @chemistry[~:1014]% pip install world
Collecting world
  Using cached world-3.1.1-py2.py3-none-any.whl
Requirement already satisfied (use --upgrade to upgrade): setuptools in 
/tmp/v/lib/python3.5/site-packages (from world)
Installing collected packages: world
Successfully installed world-3.1.1
(v) @chemistry[~:1015]% world it
it originates from ITALY
(v) @chemistry[~:1016]% deactivate

I also tried running tox with a py35 environment on a couple of my upstreams
and they worked just fine.

Can you make sure your system is fully updated and try again?  If it's still
crashing for you, then Something Else Is Going On.

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#813571: (no subject)

[Barry Warsaw]

I think this should now all be sorted out with python-virtualenv 15.0.0+ds-1
and python-pip 8.1.0-1.  I'm going to close this bug but if you're still
having a problem with those new versions, please reopen it.

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#798395: (no subject)

[Barry Warsaw]

Does this problem happen on Stretch/unstable?

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#814834: Bug#814834: (no subject)

[Barry Warsaw]

On Feb 15, 2016, at 10:23 PM, Sebastian Ramacher wrote:

>Yes, it's a bug and it will be fixed shortly. It's a serious bug in Ubuntu,
>but it's nowhere near serious in Debian. Python 3.4 is still supported. Once
>we start the transition to remove Python 3.4 from the supported set and are
>left with Python 3.5 as only supported version, it will become serious.

That may happen fairly soon.


pgpvUy5Kn2109.pgp
Description: OpenPGP digital signature
___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#814834: (no subject)

[Barry Warsaw]

Please be aware that this bug makes the package completely unusable for Python
3 users on such systems as described here.  Thus I think serious is a valid
severity.  I'll stop complaining once this bug is fixed though.  Thanks.

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#814834: pytest fails its DEP-8 tests on Python 3.5-only systems

[Barry Warsaw]

Source: pytest
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear Maintainer,

The change uploaded in 2.8.7-3 that closes #814622 and reverts the
change from 2.8.7-2 causes a critical regression in the DEP-8 tests on
Ubuntu, where only Python 3.5 exists.  Once Debian drops Python 3.4,
you will see the same regression there.

The failure is caused by there now being no Python 3 module in
dist-packages for the python3-pytest binary package.

I don't believe the change in 2.8.7-3 is correct, but since you
disagree, please ensure that the package builds and passes DEP-8 on
systems that only have Python 3.5, such as Ubuntu 16.04.


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

Kernel: Linux 4.3.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)

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJWwiReAAoJEBJutWOnSwa/HEIQAIDhM7sXjhIz7jc4SZjfLhcv
uDbNLPe4xyIqeC/hNeInTqC4+iKHeBbUnDHDP4D+b6uz07bclBJooW8mcuW7S/u8
L4Zk3pwESro/KeK5Nezb6zucan/UJTNm1G/SuLAe118GmSE8Ri76RmOaZF2/HMTx
RqxfPxQeYN3pSigvdlPPWaxMqxu2NTArQcajmJohvsXgqmaAfmOo9p3/QVuEX/t8
KddeEKTKAZUaURPKVFhFuT+0UcPiuHDXdHU0GS0tDxbLpxVR2kSgqGOVdymdOn5m
5a+0h41mkpSIzG7ZV7mdNk4CeoKZm2B1aUOxDyKIRrVIYgDeQ6U9disHJ8NpMxNL
8FlvpLN804kiuanO01ZcElJyBYxubjJmTktgXaH41gkRBQ9GJqxAL6k1otNz1auO
0plAqDsqKT2XKqZxWd4Q4KklkiPsReLJU5FUAoBI4ne3vMTjpyA1fvp9lQhSp/IZ
huV9xLAs9kGkxqK9+Li/SwbQEd/ei8Iey4XdLwDYYdt9dlGHMRfo6Jtc1DEy6Bkp
V0WztjybFrAIU3KDv5uoQpcJf/ozFHzT1RnRdHwfajhls96mxQ7hd7eKxWcm6NAd
oqpkzyawnehESa6t59fseAn4h94dNrBd47y18bluoExPSJufNUJ2C24mOnvEyfrl
JOz8nkZic6HLe37L+u6s
=8wdO
-END PGP SIGNATURE-

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#814622: Bug#814622: (no subject)

[Barry Warsaw]

On Feb 15, 2016, at 08:06 PM, Sebastian Ramacher wrote:

>This is just not true. python3.m5 -m pytest works just fine. If not, please
>file a proper bug report.

The fix you uploaded introduces a regression, albeit in Ubuntu only right now,
but it will show up in Debian once Python 3.4 is dropped.  Uploading a change
that fixes one thing but regresses another is not a proper fix.  Thus, this
bug is not resolved.


pgpiWavNMqpEO.pgp
Description: OpenPGP digital signature
___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#814622: (no subject)

[Barry Warsaw]

The reversion of 2.8.7-2 is not correct.  It breaks the DEP-8 tests in Ubuntu
where there is only Python 3.5 (and will break Debian as soon as Python 3.4 is
dropped).

By reverting this, you find that there is no Python 3 module in python3-pytest
and `python3.5 -m pytest` fails.  Please restore the change from 2.8.7-2 and
find another way to fix the problem.

Personally, I don't think we should have any Python version specific /usr/bin
scripts, but I suppose we need /usr/bin/py.test and /usr/bin/py.test-3 for
backward compatibility.  Better that people get in the habit of invoking such
tools via -m.

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#814571: Bug#814571: python-setuptools-whl and python-pip-whl: error when trying to install together

[Barry Warsaw]

On Feb 15, 2016, at 11:37 AM, Matthias Klose wrote:

>No, in the first place it's a bug to not declare a proper Breaks/Replaces.

Well, in the meantime, you uploaded a new version of python-setuptools, so the
Breaks/Replaces that already exists in python-pip is now out of date.  But if
you agree to remove python-setuptools-whl in 20.0-3, I will update the B/R in
python-pip to match it.

>And yes, you asked me to remove the whl package, but without giving a reason
>for it in your forward.

Okay, but it was discussed fairly extensively in debian-python@ already, both
in terms of the technology and the changes in Debian Python Policy, which are
already committed to its vcs.  But to re-iterate:

Through the use of dirtbike, packages which require -whls will build them at
their own build-time, but this is limited to pip and virtualenv.  Because the
dependencies of upstream pip change, this is the only viable option for
sustainability.  Thus the previous -whl packages sprinkled throughout the
archive should now be removed.

I've included the patch here.  I'm not going to play whack-a-mole with this
bug, but it will be fixed when python-setuptools-whl is removed.
diff --git a/debian/control b/debian/control
index 164dc1c..d969756 100644
--- a/debian/control
+++ b/debian/control
@@ -9,7 +9,6 @@ Build-Depends:
  python-all,
  python3-all,
  python3-sphinx,
- python3-wheel
 Build-Conflicts: python-setuptools, python3-setuptools
 Standards-Version: 3.9.6
 Homepage: https://pypi.python.org/pypi/setuptools
@@ -91,11 +90,3 @@ Depends:
 Suggests: python-setuptools-doc
 Description: PyPy Distutils Enhancements
  Extensions to the python-distutils for large or complex distributions.
-
-Package: python-setuptools-whl
-Architecture: all
-Depends: ${misc:Depends}
-Description: Python Distutils Enhancements (wheel package)
- Extensions to the python-distutils for large or complex distributions.
- .
- This package provides setuptools in PEP 427 wheel format.
diff --git a/debian/rules b/debian/rules
index d71db5a..564b847 100755
--- a/debian/rules
+++ b/debian/rules
@@ -17,10 +17,6 @@ override_dh_auto_install:
 
 	$(MAKE) -C docs html
 
-	mkdir -p debian/python-setuptools-whl/usr/share/python-wheels
-	python3 setup.py bdist_wheel --universal \
-	-d debian/python-setuptools-whl/usr/share/python-wheels
-
 	# dh_pypy from dh-python < 1.20150705-1 falls over requires.txt
 	# and our requires.txt aren't useful
 	find debian/tmp -name requires.txt -delete


pgp4Z204diS_l.pgp
Description: OpenPGP digital signature
___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#814571: Bug#814571: python-setuptools-whl and python-pip-whl: error when trying to install together

[Barry Warsaw]

On Feb 13, 2016, at 07:27 AM, Ralf Treinen wrote:

>Here is a list of files that are known to be shared by both packages
>(according to the Contents file for sid/amd64, which may be
>slightly out of sync):
>
>  /usr/share/python-wheels/setuptools-20.0-py2.py3-none-any.whl
>
>This bug has been filed against both packages. If you, the maintainers of
>the two packages in question, have agreed on which of the packages will
>resolve the problem please reassign the bug to that package. You may then
>also register in the BTS that the other package is affected by the bug.

It is a bug in setuptools and I forwarded a patch to the maintainer.  I'm
happy to NMU it if preferred.

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#813399: Bug#813399: python-pip-whl: fails to upgrade from 'testing' - trying to overwrite /usr/share/python-wheels/six-1.10.0-py2.py3-none-any.whl

[Barry Warsaw]

On Feb 12, 2016, at 01:11 PM, Andreas Beckmann wrote:

>the Breaks+Replaces against python-six-whl are insufficiently versioned,
>that package was removed in six 1.10.0-3, it is still present in -2.

I'm not sure I can make piuparts cooperate for me locally, but it's obvious
the Replaces/Breaks for python-six-whl should be bumped to 1.10.0-2, so I am
going to upload python-pip 8.0.2-6 that fixes this.

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

Re: [Python-modules-team] Git-dpm help for tweepy

[Barry Warsaw]

On Feb 11, 2016, at 09:09 AM, Ross Gammon wrote:

>I was working last night on fixing the RC bug for tweepy, but got myself
>in a muddle with git-dpm.

Yep, git-dpm will do this some times. :/

>Tweepy is currently 3.4.0 & 3.5.0 is a new available release. I cloned,
>fixed the bug (just disabling the unit test), confirmed it was fixed and
>then looked at packaging 3.5.0 as a team upload. But git-dpm seemed to
>be unaware of 3.4.0 (claiming that 3.1.0 was the right tarball), that
>there were non-debian changes in the debian branch and wouldn't let me
>import 3.5.0. So I gave up on 3.5.0, and started trying to work out what
>was wrong with 3.4.0 in git-dpm.

Occasionally I find it necessary to blow away a clone and start over, but even
then, git-dpm sometimes does mysterious things.  (This is one of several
reasons I'm beginning to sour on it, though it works just fine in the majority
of cases.)

One thing I've found is that import-new-upstream will sometimes not record the
pristine-tar, even if you use --ptc.  It seems like this can happen if you
also --rebase and are required to resolve some conflicts.  After finally
git-dpm u-p'ing the pristine-tar will not have been recorded.  Though you have
to remember to do it, it's easy enough to pristine-tar commit the new
orig.tar.gz after the fact.

The main thing is that when you update to a new upstream, be sure to git-dpm
status (and/or prepare) to be sure everything's okay before you start to work
on further changes on top of the new upstream.

Another gotcha is that if you `git clone` the repo, you won't actually have a
pristine-tar or upstream tracking branch, and this will break git-dpm.  Much
better to use `gbp clone` which does the clone and then assures you have the
local tracking branches.  If you do git clone, just be sure to checkout the
pristine-tar branch before you start working on things (and upstream too,
though this matters less in practice).

(Aside: I'm not sure I'd say that disabling a unit test counts as a "fix" ;)

I don't know if any of the above is relevant for your case.  I've seen git-dpm
do weird things like take a single commit in the patches branch and turn it
into a quilt patch where the diff is present *twice*.  I think this was for a
simple fix in pyparsing (trying to change distutils.setup() into
setuptools.setup() in the setup.py), and though I tried a ton of different
things, I was never able to get git-dpm to generate a correct quilt patch
file.

>At this point, I somehow merged pristine-tar into master :-(

You'll be way better off restarting from a fresh clone than trying to fix your
busted one.  That way leads to madness. ;)

Cheers,
-Barry


pgpU5s97Zyw0Q.pgp
Description: OpenPGP digital signature
___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#725848: (no subject)

[Barry Warsaw]

Since upstream hasn't changed the default yet, and for understandable reasons
it isn't high on their priority list, and because I'm tired of carrying the
Ubuntu delta that switches to --user by default, I am going to port the Ubuntu
patch to the Debian version.  This will let me resync to Debian and only have
to maintain one version.

Note that Didier's patch does add a --system switch which overrides the
default --user, so I think that should address any usability concerns.

Donald, I appreciate that upstream will do this Right And Better, and once it
does, I'll happily drop this patch.  I agree it kind of sucks that we have to
change upstream's behavior here, but doing so seems like the least worst thing
to do while we wait.

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#725848: (no subject)

[Barry Warsaw]

On Feb 10, 2016, at 11:43 AM, Donald Stufft wrote:

>Can we at least ensure that $HOME/.local/bin is on the $PATH by default if
>you’re going to do that?

How can we do that?  Not in python-pip certainly.  Users control their own
$PATH so I'm not sure how we can enforce that.  I'm not sure what the Debian
default $PATH is.

>Can the documentation for —system include a note that it is a Debian specific
>option? Possibly link to the upstream issue or something?

Yep, I made sure that the documentation for --user and --system describe that
they are Debian-specific.


pgpIzKPUzigWh.pgp
Description: OpenPGP digital signature
___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#814069: python-six-whl and python-pip-whl: error when trying to install together

[Barry Warsaw]

On Feb 08, 2016, at 10:51 AM, Colin Watson wrote:

>Looks like https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813399, but
>more of the same.  Barry, shouldn't you be doing something like
>"python-six-whl (<< 1.10.0+)", rather than these sketchy <= dependencies
>on specific packaging revisions that are going to break when we do
>something innocuous in six?
>
>The whole way this devendoring is handled seems very very sketchy
>anyway.  I take it that you're trying to ensure that pip has
>exactly-versioned wheels available even when (e.g.) six moves on to a
>newer upstream version?  In that case, I suggest finding a way to ship
>the necessary wheels in a directory private to pip instead of in
>/usr/share/python-wheels/.  We really shouldn't be deliberately shipping
>the same file in two different packages for more than just temporary
>transitional purposes.
>
>> Here is a list of files that are known to be shared by both packages
>> (according to the Contents file for sid/amd64, which may be
>> slightly out of sync):
>> 
>>   /usr/share/python-wheels/six-1.10.0-py2.py3-none-any.whl
>> 
>> This bug has been filed against both packages. If you, the maintainers of
>> the two packages in question, have agreed on which of the packages will
>> resolve the problem please reassign the bug to that package. You may then
>> also register in the BTS that the other package is affected by the bug.  
>
>I would be inclined to argue that this path clearly belongs to the
>python-six-whl package.  Barry, do you agree with me reassigning this
>bug to python-pip-whl?

-whl packages really only exist for pip and virtualenv.  As per Debian Python
policy, they shouldn't be used for anything else in the archive.  It used to
be that the only way we could provide those .whl files was to build them when
we built the dependent packages, thus we had to add python-six-whl and others.

But now we have dirtbike, which is a tool to turn .deb provided packages back
into wheels, so pip and virtualenv build whatever they need using dirtbike in
their own d/rules files, and have Built-Using headers to at least document
this; or at least *did* - it looks like some things got lost or mis-merged
from an earlier branch :(

So where we ultimately want to end up is that python-six-whl and the others go
away.  Instead, we'll have only python-pip-whl and another -whl package in
virtualenv to provide a few additional requirements.  I haven't uploaded or
file bugs for the appropriate changes in the dependent packages yet.  I
thought I had everything working locally and ready to go, but I've run into a
few snafus which I'm still working out.

Anyway, that's the plan.  As you mention, this really is a transitional period
and I thought it would go more smoothly.  /usr/share/python-wheels will not
have two paths owned by two different packages once this is done.  Debian
Python Policy has been updated in bzr but not yet pushed out (there are other
unrelated changes pending).

You're right Colin, that this bug really belongs in pip and I think it should
be duped to #813399; which I closed over the weekend, but maybe not
correctly.  You might be right about the << dependencies, in which case, let's
keep this bug (#814069) as a separate bug, but move it to python-pip.

Hopefully that makes sense.  Apologies for all the brokenness I've introduced.
I had some work priorities that unfortunately interrupted this transition, but
I'll be working only on this transition now until it's all fixed.


pgpc808kzT3Wi.pgp
Description: OpenPGP digital signature
___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

Re: [Python-modules-team] Bug#813399: python-pip-whl: fails to upgrade from 'testing' - trying to overwrite /usr/share/python-wheels/six-1.10.0-py2.py3-none-any.whl

[Barry Warsaw]

On Feb 01, 2016, at 04:24 PM, Andreas Beckmann wrote:

>during a test with piuparts I noticed your package fails to upgrade from
>'testing'.
>It installed fine in 'testing', then the upgrade to 'sid' fails
>because it tries to overwrite other packages files without declaring a
>Breaks+Replaces relation.
>
>See policy 7.6 at
>https://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces
>
>>From the attached log (scroll to the bottom...):  
>
>  Selecting previously unselected package python-pip-whl.
>  Preparing to unpack .../python-pip-whl_8.0.2-2_all.deb ...
>  Unpacking python-pip-whl (8.0.2-2) ...
>  dpkg: error processing archive 
> /var/cache/apt/archives/python-pip-whl_8.0.2-2_all.deb (--unpack):
>   trying to overwrite 
> '/usr/share/python-wheels/six-1.10.0-py2.py3-none-any.whl', which is also in 
> package python-six-whl 1.10.0-1
>  dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
>  Errors were encountered while processing:
>   /var/cache/apt/archives/python-pip-whl_8.0.2-2_all.deb

python-pip-whl has Breaks/Replaces, but it looks like I got the version
specifications wrong.

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#813162: Bug#813162: python3-pip: missing dependencies

[Barry Warsaw]

Hi Sebastian,

On Jan 30, 2016, at 01:34 AM, Sebastian Ramacher wrote:

>This was an upgrade and python-pip-whl version 1.5.6-7 is installed.

You definitely need python-pip-whl 8.0.2-1

Did that not install when you upgraded?


pgpPAmE6Gucb1.pgp
Description: OpenPGP digital signature
___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

Re: [Python-modules-team] Bug#813162: python3-pip: missing dependencies

[Barry Warsaw]

On Jan 30, 2016, at 01:07 AM, Sebastian Ramacher wrote:

>After installing python3-cachecontrol, python3-lockfile, python3-packaging,
>python3-progress and python3-retrying, pip3 no longer fails with ImportErrors.

Those shouldn't be necessary.  Was this an upgrade or a fresh install of these
packages?  Do you have python-pip-whl installed?


pgplSgKQLiHQc.pgp
Description: OpenPGP digital signature
___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#810139: (no subject)

[Barry Warsaw]

Ultimately, this is a bug in Cython, which upstream is aware of and should fix
by Python 3.6.  I reverted the change in upstream Python 3.5 (and 2.7) since
it's technically a regression.  Matthias has cherry picked the fix for
Ubuntu's Python 3.5; I assume but am not sure if he's also done the same for
Debian.

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#804558: Bug#804558: tweepy: FTBFS: ImportError: No module named {unittest2, vcr}

[Barry Warsaw]

On Jan 04, 2016, at 10:43 AM, Carl Chenet wrote:

>We have a RC bug for Tweepy in Debian because the unittest2 and/or vcr
>Python modules are not packaged for Debian

Not correct.  Both packages are in Debian for both Python 2 and 3.

We have unittest2 1.1.0-6 and vcr 1.7.3-1

There must be some other build problem going on.

>Tell me if I'm wrong but unittests executions are not mandatory by
>Debian policy while building a Debian package.

Probably not mandatory, but good practice.  Sometimes it's not possible to run
a package's test suite at build time for various reasons.  In those cases, I
think it's good practice to write a DEP-8 autopkgtest to at least test the
installed package.

Cheers,
-Barry

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#808763: Bug#808763: Running pytest

[Barry Warsaw]

On Dec 23, 2015, at 07:20 PM, Tristan Seligmann wrote:

>If you want to run pytest with a particular version of python, then
>"pythonX.Y -m pytest" is a much better way than relying on the py.test-X.Y
>scripts.

Sorry, I've had no time to respond in detail, but in general I agree with
this.  It's true of any version-specific script (e.g. pip) even if it is a
less user-friendly ui.

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

Re: [Python-modules-team] Django 1.9

[Barry Warsaw]

On Nov 25, 2015, at 06:09 PM, Brian May wrote:

>Looks like the referenced ticket contains old information.
>
>https://github.com/django/django/commit/d27085b02d58ecf8b72e7189b6a5feaf634ec977

This is great news.  I just built the 1.8.5-2ubuntu1 version in Xenial, which
runs the test suite under python3 - i.e. python3.5.  Everything passes.
Ubuntu is a merge behind Debian's 1.8.7-2 and it looks like we should probably
do the merge to pick up the official support for Python 3.5 added in 1.8.6.

Thanks everyone!
-Barry


pgpFclWHDzrHP.pgp
Description: OpenPGP digital signature
___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Django 1.9

[Barry Warsaw]

Hi guys, apologies for any duplicate emails.

I really appreciate all the great work y'all have done to get us on Django
1.8.  I was hoping that this would give us Python 3.5 support, but as you
know, upstream's documentation is incorrect about this, and then there's issue
25502 tracking *actual* Python 3.5 support.

Also, Django 1.9rc1 was released last week and their roadmap says that 1.9
final should be out possibly by next week (2 weeks after rc1 if no rc2 is
necessary).  1.9 *will* officially support 3.5.

What's the plan for Django 1.9?

Cheers,
-Barry


pgpuqHrJFy6XA.pgp
Description: OpenPGP digital signature
___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#803188: numpydoc: lintian warnings about debian/copyright

[Barry Warsaw]

Source: numpydoc
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear Maintainer,

debian/copyright produces a bunch of lintian warnings:

W: numpydoc source: empty-short-license-in-dep5-copyright (paragraph at line 5)
W: numpydoc source: empty-short-license-in-dep5-copyright (paragraph at line 32)
W: numpydoc source: empty-short-license-in-dep5-copyright (paragraph at line 58)
W: numpydoc source: file-without-copyright-information LICENSE.txt
W: numpydoc source: file-without-copyright-information MANIFEST.in
W: numpydoc source: file-without-copyright-information PKG-INFO
W: numpydoc source: file-without-copyright-information README.rst
W: numpydoc source: file-without-copyright-information 
numpydoc.egg-info/PKG-INFO
W: numpydoc source: file-without-copyright-information 
numpydoc.egg-info/SOURCES.txt
W: numpydoc source: file-without-copyright-information 
numpydoc.egg-info/dependency_links.txt
W: numpydoc source: file-without-copyright-information 
numpydoc.egg-info/top_level.txt
W: numpydoc source: file-without-copyright-information numpydoc/__init__.py
W: numpydoc source: file-without-copyright-information numpydoc/comment_eater.py
W: numpydoc source: file-without-copyright-information 
numpydoc/compiler_unparse.py
W: numpydoc source: file-without-copyright-information numpydoc/docscrape.py
W: numpydoc source: file-without-copyright-information 
numpydoc/docscrape_sphinx.py
W: numpydoc source: file-without-copyright-information umpydoc/linkcode.py
W: numpydoc source: file-without-copyright-information numpydoc/numpydoc.py
W: numpydoc source: file-without-copyright-information umpydoc/phantom_import.py
W: numpydoc source: file-without-copyright-information 
numpydoc/plot_directive.py
W: numpydoc source: file-without-copyright-information 
numpydoc/tests/test_docscrape.py
W: numpydoc source: file-without-copyright-information 
numpydoc/tests/test_linkcode.py
W: numpydoc source: file-without-copyright-information 
numpydoc/tests/test_phantom_import.py
W: numpydoc source: file-without-copyright-information 
numpydoc/tests/test_plot_directive.py
W: numpydoc source: file-without-copyright-information 
numpydoc/tests/test_traitsdoc.py
W: numpydoc source: file-without-copyright-information numpydoc/traitsdoc.py
W: numpydoc source: file-without-copyright-information setup.cfg
W: numpydoc source: file-without-copyright-information setup.py

I'd be willing to sponsor an upload fixing these.

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

Kernel: Linux 4.2.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)

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJWL9WfAAoJEBJutWOnSwa/aUUP/jj2BbQrLItLopC/zN6AgFbr
Se+GgP0KyuiuY0MYxotKfeUXB1dfb+VUfXzqv0lXfz6IP8+5voqItCE2U5j5R0hN
AuT81CiW9JHt/DQBYT1Rkl60qe2hhH7dkgeR3pSswPqb0AuAM8yblGrE/LJSoSVC
GriYqGLop5vysZ40cUbLsSups63vU5mP+dCO9PB4JwnIinXwdeLZz6ElD9D2UuVJ
ThRTMDLkuHiJ8n4zv/7FaRUmISyPnWkIgtHdfeW12IJzh7/QPsBGsDwah+ddtrMP
vLrzGwysM1KDTDSNIxC/T5bDuV4XmYNvUFo8eZPdOw2ZIFjH9QYP56rrgCwWHEJ5
2SxiYdIA7eFX5GiwC3UZsRh64iMWDuYxFx/AL6uzPaFg38rDH+CZex8/XxqYOrCt
/aPFR+m0vkju/OYLTHu/9UswoShOinb5oTaXQUzFkYlVn6yU7/EtvamUuSAKZpUD
wvTvvxkaymAM9+opxbouPDZ3ef6Pqvg8FwPLoNnMGOHs+EXlmkugbJu/d1Dg2CyS
DU/DKcqnFIu01fkaSwRKd81nSb6ttDxPtefjFkvcQY8X0VsOYdwzLwtUeRawM6WD
CCGs07hPwoWsYsZqIhFVCnRsS1GIzSE7+meJafqLzMPmWDFm79HbYrE+6gVMWlr7
Kb2CBP6wkClQIU6C58yC
=KPo7
-END PGP SIGNATURE-

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#789670: (no subject)

[Barry Warsaw]

I think the best we can do is add a Conflicts between the two packages.  The
contents of the conflicting directories are different.  Personally, I think
it's a bug that the two upstreams install these into the top-level namespace,
but given the nature of the packages, I can see why they did it this way.

I'll upload a Conflicts for future and will begin the NMU for python-pies.


pgpWnqhckvMTJ.pgp
Description: OpenPGP digital signature
___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#795594: (no subject)

[Barry Warsaw]

I'm attaching a diff against current svn which fixes the d/copyright issue.
It also makes some other changes which fixes the d/watch file and updates the
package to Babel 2.0 and cldr 27.  I'm not applying it because the package
doesn't build - the test fail.  I don't think upstream supports v27 yet.
OTOH, I don't want to lose these changes.  Apologies for attaching them to
this bug instead of opening a new bug.
Index: debian/changelog
===
--- debian/changelog	(revision 34223)
+++ debian/changelog	(working copy)
@@ -1,3 +1,20 @@
+python-babel (2.0+dfsg.1-1) UNRELEASED; urgency=medium
+
+  * Team upload.
+  * New upstream release.
+  * debian/copyright: Fill out the `Files: common/*` section to include
+the Unicode license agreement.  (Closes: #795594)
+  * debian/control: Update Standards-Version to 3.9.6 with no other
+changes necessary.
+  * debian/patches:
+- 0001-Fixup-get_currency_name-test.patch: Removed, applied upstream.
+- adds-support-for-python-3.2.patch: Removed, no longer necessary.
+- fix-sphinx-conf.py-to-avoid-intersphinx.patch: Refreshed.
+  * debian/repack: Update Unicode core.zip location.
+  * debian/watch: Use the pypi.debian.net redirector.
+
+ -- Barry Warsaw <ba...@debian.org>  Thu, 10 Sep 2015 15:25:31 -0400
+
 python-babel (1.3+dfsg.1-5) unstable; urgency=medium
 
   * Team upload.
Index: debian/control
===
--- debian/control	(revision 34223)
+++ debian/control	(working copy)
@@ -15,7 +15,7 @@
python3-setuptools,
python3-six,
python3-tz
-Standards-Version: 3.9.4
+Standards-Version: 3.9.6
 Homepage: http://babel.pocoo.org/
 Vcs-Svn: svn://anonscm.debian.org/python-modules/packages/python-babel/trunk/
 Vcs-Browser: http://svn.debian.org/viewsvn/python-modules/packages/python-babel/trunk/
Index: debian/copyright
===
--- debian/copyright	(revision 34223)
+++ debian/copyright	(working copy)
@@ -12,7 +12,58 @@
 License: GPL-2
 
 Files: common/*
-Copyright:
+Copyright: © 1991-2013 Unicode, Inc.
+License: Unicode
+ UNICODE, INC. LICENSE AGREEMENT - DATA FILES AND SOFTWARE
+ .
+ Unicode Data Files include all data files under the directories
+ http://www.unicode.org/Public/, http://www.unicode.org/reports/, and
+ http://www.unicode.org/cldr/data/. Unicode Data Files do not include PDF
+ online code charts under the directory http://www.unicode.org/Public/.
+ Software includes any source code published in the Unicode Standard or under
+ the directories http://www.unicode.org/Public/,
+ http://www.unicode.org/reports/, and http://www.unicode.org/cldr/data/.
+ .
+ NOTICE TO USER: Carefully read the following legal agreement. BY DOWNLOADING,
+ INSTALLING, COPYING OR OTHERWISE USING UNICODE INC.'S DATA FILES ("DATA
+ FILES"), AND/OR SOFTWARE ("SOFTWARE"), YOU UNEQUIVOCALLY ACCEPT, AND AGREE TO
+ BE BOUND BY, ALL OF THE TERMS AND CONDITIONS OF THIS AGREEMENT. IF YOU DO NOT
+ AGREE, DO NOT DOWNLOAD, INSTALL, COPY, DISTRIBUTE OR USE THE DATA FILES OR
+ SOFTWARE.
+ .
+ COPYRIGHT AND PERMISSION NOTICE
+ .
+ Copyright © 1991-2013 Unicode, Inc. All rights reserved. Distributed under
+ the Terms of Use in http://www.unicode.org/copyright.html.
+ .
+ Permission is hereby granted, free of charge, to any person obtaining a
+ copy of the Unicode data files and any associated documentation (the "Data
+ Files") or Unicode software and any associated documentation (the "Software")
+ to deal in the Data Files or Software without restriction, including without
+ limitation the rights to use, copy, modify, merge, publish, distribute, and/or
+ sell copies of the Data Files or Software, and to permit persons to whom the
+ Data Files or Software are furnished to do so, provided that (a) the above
+ copyright notice(s) and this permission notice appear with all copies of the
+ Data Files or Software, (b) both the above copyright notice(s) and this
+ permission notice appear in associated documentation, and (c) there is clear
+ notice in each modified Data File or in the Software as well as in the
+ documentation associated with the Data File(s) or Software that the data or
+ software has been modified.
+ .
+ THE DATA FILES AND SOFTWARE ARE PROVIDED "AS IS", WITHOUT WARRANTY OF ANY
+ KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OF THIRD
+ PARTY RIGHTS. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR HOLDERS INCLUDED IN
+ THIS NOTICE BE LIABLE FOR ANY CLAIM, OR ANY SPECIAL INDIRECT OR CONSEQUENTIAL
+ DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR
+ PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS
+ ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR P

[Python-modules-team] Bug#798023: cssutils: FTBFS with Python 3.5

[Barry Warsaw]

Source: cssutils
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

cssutils 1.0-2 fails to build from source with Python 3.5.

The upstream bug report is here:

https://bitbucket.org/cthedot/cssutils/issues/52/bad-octal-escape-blows-up-on-python-35b3


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

Kernel: Linux 4.1.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

iQIcBAEBCAAGBQJV6au9AAoJEBJutWOnSwa/RFYP/0P7uMB2KKEo7VUwc2cFhib4
7DWwpildYSUqrDBFA4olOgQGiDQvS7k8Q77pAonHCiqkK7QMZmYr+8lnPp2zD/Im
FyMeGoaTrXREddoUEUbwWdoVXMC646a4RL3upeuiAjOjn6GvXRiwX+ng6ShQGtFk
kse6fjJyo42hE0sOCitSXJ2NgzhxJ1EqtJ5wv+OgRFeRm9xTYV5E2bp5gD3VLIa0
sHOXul2+sqlBaoTr6bOrb9cvErhDMAFMRGubYJpOA3LXgpRK54vKEO8D8cWImHGc
qboCQTiLIvR46lzooGhWqAROH6oD6BryxEH7PpQqKinLUotDhAlQAPvUEyBKdli4
xuM7kkQ1JPil2bj4o0NBPyKLo8hs8kk77C8kCoFBeQN1CGxzVACJ7PWmcd2/qErl
yC3rRzA5km1phosH2aCOD7yBXoe2BikuUvOFNTDiZ5Muoi9SZ0F/B3axmZ1efaZe
B+oG1fDw7z2hpxT509bbFej5wSp4+ncHyXuaDig1/EuQzU+UUI7sk7uqdbT6f/CD
ctcEjwnFIX4sljdALDYjhRxJmol689hGIcdyfQFYvdDVyGfXwsO71x7qyJnqWizf
64wqBC9nABrB0fLdSdlE8FlfuHY+UEGqeZfsRxQ8N6P+AnRVslv+REc5pCeYMlwo
PUjzEpF/ukt9+dkdrgo/
=sEez
-END PGP SIGNATURE-

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#798030: genshi: FTBFS with Python 3.5

[Barry Warsaw]

Source: genshi
Severity: important
Owner: !

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

genshi 0.7-3 currently FTBFS with Python 3.5.  Upstream ticket is
http://genshi.edgewall.org/ticket/602 which contains a patch, although
this doesn't completely solve the problem for me.  This is a tracking
bug as I'm currently still working on a fix.


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

Kernel: Linux 4.1.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

iQIcBAEBCAAGBQJV6b/pAAoJEBJutWOnSwa/dFUQALmLBXN1OOpmheyJ36RqJftq
mk9NrOSGVD3KL5RE+UDDut5YQTsVPU+cNLhR/kM++yW+FABpLAD8UAj5FAs9Hti/
CLRsn56tJHl/mYIxtYig6xTEyMAL79xrXvNMqTyOeQRAWC4m48VLQYBoeM92k1Ug
jm8qHKHdETqFRsu9kV00H5FoPlD3BpbAaDrHwGjK0tCVSzLJ/wI0rNiFanIQGL+j
EBmgHeAw20zDJitUCAC+OUjdAVZ9mGQkg92LDYhpgNRbktz/aErtjf9ezb3mj84P
U8uHLaG/zDiGAmFvEnN9/GAjppBAOk/ItrBQgTSmsSL5kIm+wG8l7LlA1xkXgbY+
cdnxoukO9tHNfdS14Qks2mMXK8SAqKPqkxroAgtHF253un0YL+NXQH7e8xoAFUIR
tPT+HaP9n+bwJpAWeGT/OhXGXWVaqym3C4SPno3Z8NWipRzOlhj701kKM5l/hjbK
UBb3Rlvkee0i67R/jAu79h6KT096EhrFWM8BhISoo5iNYjcGX1FTEKxjIvoNxyH4
P4pvGBSRJdd2sqsXvtHn3SiCLtJ7v3N7mb713hJM70UFpDOGp2Vq9fKp6WvFcY/D
0FhzSsPVr9ab5KJT+rtu4+2qj2j8S9BkH37sy4wfrmy0LmOchC6l30TIVAB8d+ep
x3OEm1qjeDb3/TOrBW49
=FVNa
-END PGP SIGNATURE-

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

Re: [Python-modules-team] Jessie Wheezy backport for python-pex

[Barry Warsaw]

Hi Sandro,

On Jul 14, 2015, at 02:59 PM, Sandro Tosi wrote:

we want to start experimenting with python-pex, so we would need a
backport to Jessie and Wheezy: would you handle them yourself or would
you mind me preparing them?

I'm planning on updating unstable to 1.0.1 today, but I'm not sure I'll have
time soon to work on the backport.  Would you mind starting that and I'd be
happy to review it?

Cheers,
-Barry


pgp22KoZmSx8o.pgp
Description: OpenPGP digital signature
___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#788383: (no subject)

[Barry Warsaw]

Oops, of course I forgot to mention the change to d/rules in the changelog
entry, but you can fix that. :)

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#788383: python-requests: Better devendorization

[Barry Warsaw]

Package: python-requests
Version: 2.7.0-2
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear Maintainer,

In https://github.com/kennethreitz/requests/pull/2567 upstream is
considering a patch to make it easier for Debian and other downstream
consumers to devendorized the bundled urllib3 and chardet libraries.
I've done some extensive testing of this as you can see in my comment
on the above PR.  Attached is a patch against the Debian svn package
branch for python-requests which drops two previous quilt patches and
adds a new one which includes the proposed upstream PR.  From my
testing it seems to do everything we need it to do with a minimum of
delta from upstream.  Even less if/when upstream merges the PR!

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

Kernel: Linux 4.0.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-requests depends on:
ii  ca-certificates  20150426
ii  python-chardet   2.3.0-1
ii  python-urllib3   1.10.4-1
pn  python:any   none

python-requests recommends no packages.

Versions of packages python-requests suggests:
ii  python-ndg-httpsclient  0.3.2-1
ii  python-openssl  0.14-1
ii  python-pyasn1   0.1.7-1

- -- no debconf information

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJVeJvCAAoJEBJutWOnSwa/RdcQAJotaexzbqse4Tr5W++yZNCb
Pj4KJ1KYIiXvR15741uwiQ38LTndpAaWU88mklHOz3Pp77ztMlztyseSz0qZlQ/A
RFZ5DS3dlybWwqg/1rxCNv3nd8iv0Ex2M3TahqkcOxYmXmwArBFdH5TGXs1tmV3h
NbizvXLHX2x1ZfsWemtgCyGR37EfdfUeZqFi2R6UXl8sH+8xbudaNb77fT4Hm+98
rhiA/5QU39/m1w7/yE38XDu35n3+idUksK3B769xKnshBNG1/7UvO0skcPfWm7kf
PVPqow5ZZqKCr4nZWJZDPRlp4nYhYt0loFfRbbntef0nX+fYXRLT9Go6UsBlFixf
wiXdVY/NaoCCdS26Mi/2ByODddSTkdVarjt3Yp/0TSzRnwyVDHVpT1mjQQDS8iMY
KaKbcjbmiGPYraI3Oe6uzWgmi9A3UjUF3onpf6uJYcTw/TPN580Ko5oia5ByCc4D
thgorRks2TRHAvPuvqKUvWM8uxcOUOqW819sdVxy5jDhuLrYCUXqQVDzSKbkyNQn
gsQqfNUGEd9Ct1XIyei4K0lmyXjf1Oy3Z2xTnokzn7xgWqwM1MhkgHElseB7sJD8
r0itJIPfo7KbD/pQGlZwM7KwVy5Fw2YjGKdXnfIie38XcGOu9Jhm1XFAtXbXovm3
MEUExmUbDxN+6kvtcXt0
=LE0a
-END PGP SIGNATURE-
Index: debian/changelog
===
--- debian/changelog	(revision 32945)
+++ debian/changelog	(working copy)
@@ -1,3 +1,14 @@
+requests (2.7.0-3) UNRELEASED; urgency=medium
+
+  * debian/patches:
+- 02_use-system-chardet-and-urllib3.patch and
+  04_make-requests.packages.urllib3-same-as-urllib3.patch: Removed in
+  favor of upstream's pull request #2567
+- 05_upstream_devendorize.patch: Upstream's pull request to better
+  support the devendorizing of urllib3 and chardet.
+
+ -- Barry Warsaw ba...@debian.org  Wed, 10 Jun 2015 12:28:58 -0400
+
 requests (2.7.0-2) unstable; urgency=medium
 
   * Upload to unstable.
Index: debian/patches/02_use-system-chardet-and-urllib3.patch
===
--- debian/patches/02_use-system-chardet-and-urllib3.patch	(revision 32945)
+++ debian/patches/02_use-system-chardet-and-urllib3.patch	(working copy)
@@ -1,129 +0,0 @@
-Description: Use the system python-chardet and python-urllib3 instead of the
- embedded copies but provide requests.packages package because it will be
- used to supply a stub for ``requests.packages.urllib3``.
-Author: Daniele Tricoli er...@mornie.org
-Forwarded: not-needed
-Last-Update: 2015-05-04
-
 a/requests/adapters.py
-+++ b/requests/adapters.py
-@@ -11,22 +11,22 @@
- import socket
- 
- from .models import Response
--from .packages.urllib3.poolmanager import PoolManager, proxy_from_url
--from .packages.urllib3.response import HTTPResponse
--from .packages.urllib3.util import Timeout as TimeoutSauce
--from .packages.urllib3.util.retry import Retry
-+from urllib3.poolmanager import PoolManager, proxy_from_url
-+from urllib3.response import HTTPResponse
-+from urllib3.util import Timeout as TimeoutSauce
-+from urllib3.util.retry import Retry
- from .compat import urlparse, basestring
- from .utils import (DEFAULT_CA_BUNDLE_PATH, get_encoding_from_headers,
- prepend_scheme_if_needed, get_auth_from_url, urldefragauth)
- from .structures import CaseInsensitiveDict
--from .packages.urllib3.exceptions import ConnectTimeoutError
--from .packages.urllib3.exceptions import HTTPError as _HTTPError
--from .packages.urllib3.exceptions import MaxRetryError
--from .packages.urllib3.exceptions import ProxyError as _ProxyError
--from .packages.urllib3.exceptions import ProtocolError
--from .packages.urllib3.exceptions import ReadTimeoutError
--from .packages.urllib3.exceptions import SSLError as _SSLError
--from .packages.urllib3.exceptions import ResponseError
-+from urllib3.exceptions import ConnectTimeoutError
-+from urllib3.exceptions import HTTPError as _HTTPError
-+from urllib3

[Python-modules-team] Bug#787165: (no subject)

[Barry Warsaw]

This is almost certainly related to the distlib 0.2.0 update which manifest in
bug #785787 (and was fixed there for that example).  We'll keep running into
these until I can finish the pip 7 work.


pgpk_T7EaHdb3.pgp
Description: OpenPGP digital signature
___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#786440: (no subject)

[Barry Warsaw]

@Felix: Actually the pip_util.diff is only relevant for bug #758787.  I've
tested what will be pip 1.5.6-6 with that patch and it isn't relevant for bug
#786440 afaict.

I'm inclined not to fix this for the 1.5.6 series, and just concentrate on
getting (now) pip 7 into Debian.


pgptAmkmY7fko.pgp
Description: OpenPGP digital signature
___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#744145: (no subject)

[Barry Warsaw]

ScottK and I discussed this and we agreed that the change is necessary, and
that the severity of this bug should be bumped to serious.  We also need to
make a change to Debian Python Policy to more accurately reflect the
restriction on wheel files.  I will handle both of these changes.

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#744145: (no subject)

[Barry Warsaw]

I have committed a fix for this to python-pip's svn and sent a message with
the relevant details to debian-python@.  The bug and its fix are pretty
simple.  Instead of only putting the .whl files early on sys.path when inside
a venv, we should be doing that in all cases.  The only inside/outside
difference is the location of the wheel files.

I think this should be reclassified back to severity grave and the fix
included in Jessie.

https://lists.debian.org/debian-python/2015/02/msg00082.html

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#771794: pip silently removes/updates system provided python packages

[Barry Warsaw]

On Dec 02, 2014, at 10:38 PM, Scott Kitterman wrote:

Speaking only for myself, I think that sounds reasonable.

It's well established I believe in Debian Python usage that if a user
installs packages in /usr/local and break their system, they are on their
own, so I'm not particularly worried about the edge cases for having the same
python package installed in /usr/lib and /usr/local, it's on whoever
installed stuff in /usr/local.

Work's been busy for me lately, but I'll just chime in with a +1

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#771794: Bug#771794: pip silently removes/updates system provided python packages

[Barry Warsaw]

On Dec 03, 2014, at 03:20 PM, Piotr Ożarowski wrote:

IMO we should patch pip to *not* touch (install, upgrade, uninstall,
etc.) anything in /usr directory (or /) except /usr/local. Our Python
interpreter already installs to /usr/local and so should pip.

+1

This way:
 * pip doesn't need to figure out which file can be touched,
 * we can detect cause of problems just by looking at traceback
   (right now the very first thing I do once someone sends me a
   traceback is to look for .egg files in there (thank you ez_install!);
   with pip installing/overwriting files in /usr instead of /usr/local
   it's not that easy, not to mention that it will be a lot harder to
   fix it after such install)
 * we'll be able to easily prove to our users that we're not insane
   and we did test our stuff (please rename
   /usr/local/pythonX.Y/dist-packages to something else for few minutes
   and try again)

Don't forget that `$python -S` disables `import site` which has the side
effect of not including /usr/local on sys.path.  E.g.

% python3 -c import sys; print(sys.path)
['', '/home/barry/env/python', '/usr/lib/python3.4', 
'/usr/lib/python3.4/plat-x86_64-linux-gnu', '/usr/lib/python3.4/lib-dynload', 
'/home/barry/.local/lib/python3.4/site-packages', 
'/usr/local/lib/python3.4/dist-packages', '/usr/lib/python3/dist-packages']
% python3 -S -c import sys; print(sys.path)
['', '/home/barry/env/python', '/usr/lib/python3.4/', 
'/usr/lib/python3.4/plat-x86_64-linux-gnu', '/usr/lib/python3.4/lib-dynload']

Unfortunately, as you can see, this also disables
/usr/lib/python3/dist-packages so it it's a perfect way of telling people
let's disable any non-apt managed packages.

I would support adding a special Debian -X switch which removes /usr/local
paths from sys.path.  Then, if you suspect some local outside-apt
customization is causing them problems you can ask them to run:

$ python3 -X ignore-debian-usr-local-customizations

(spelling TBD)

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#770173: (no subject)

[Barry Warsaw]

I hope you don't mind if I beat you to it? ;)

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#752467: (no subject)

[Barry Warsaw]

The weird package relationships are due to the interaction between historical
baggage, Debian Python policy, and the port of the cli to Python 3.

python-foo should only be for Python 2 compatible libraries, while python3-foo
is for the Python 3 compatible libraries.  Back when python-virtualenv (src
pkg) was the only thing available, it also contained /usr/bin/virtualenv, but
that won't work now that we want to provide both the Python 2 and 3 compatible
libraries.  Also, because /usr/bin/virtualenv is shebanged to python3, it also
doesn't make sense to include it in the python-virtualenv binary package.

The typical solution is to move the /usr/bin script (and manpage, etc.) into a
separate binary package, and it makes the most sense to call this
'virtualenv'.  Because /usr/bin/virtualenv is a Python 3 script, it Depends on
python3-virtualenv.  There are use cases for keeping python-virtualenv as a
separate Python 2-compatible library that would e.g. be importable.

The question still remains: how best to upgrade people who have
/usr/bin/virtualenv provided by python-virtualenv in Wheezy, so that they now
get /usr/bin/virtualenv provided by virtualenv in Jessie?  Using Recommends
was an attempt at that, but clearly it's not good enough.

Hopefully that explains most of the new arrangement.  The only questionable
dependency is the Recommends.  I'm not sure what better we can do.  We should
not add a Depends from python-virtualenv to virtualenv (and thus transitively
to python3-virtualenv) because then people might get a library they don't care
about (i.e. python-virtualenv).  virtualenv does Breaks/Replaces older
versions of python-virtualenv, but I guess that's not enough either.

I don't see how adding a Provides can help, unless we push an update to Wheezy
such that python-virtualenv `Provides: virtualenv`.  Would that work?  If not,
I don't really see any other package relationship declaration that we can use
to make this upgrade go more smoothly.  Suggestions welcome!

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#752467: Bug#752467: (no subject)

[Barry Warsaw]

On Nov 18, 2014, at 09:39 AM, Brian May wrote:

For another solution, have a look at django-admin, provided by the
django-common package. You can call it using any of the following ways:

brian@aquitard:~$ django-admin# run as sh; autodetect python

Yep, that autodetect is clever.  Such a thing does often come up.

brian@aquitard:~$ python2 /usr/bin/django-admin# force python 2
brian@aquitard:~$ python3 /usr/bin/django-admin# force python 3

If a script is shebanged with one Python version or another, this is always
possible.  I use it in fact to run /usr/bin/python-coverage with a
virtualenv'd python.

That way it works if only python-django is installed and it also works if
only python3-django is installed.

The ability to force a particular version of python may not be so useful
for virtualenv however.

I don't think it is, since you can still create virtualenvs of whatever Python
you want with the -p option, regardless of what the virtualenv script is
shebanged.

The problem here is how to specify the package dependencies such that someone
who only has python-virtualenv installed in Wheezy, would automatically get
virtualenv in Jessie, for the /usr/bin script.


signature.asc
Description: PGP signature
___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#767554: python-persistent and python-zodb: error when trying to install together

[Barry Warsaw]

On Nov 12, 2014, at 05:50 PM, Arnaud Fontaine wrote:

From upstream point  of view, ZODB3 (aka python-zodb in  Debian) used to
include persistent, BTrees,  ZODB and ZEO modules.  However, since ZODB3
3.11.0a1, upstream  has split it  up into  4 distinct packages  (one for
each module),  bump the version  to 4.0  and made ZODB3  a metapackage
depending on all of them.

It looks like Debian still has zodb 3.9.7, right?

As of  fixing this RC  bug for Jessie:  Among the four,  only persistent
package is currently available in Debian, so  there is no way to get rid
of  ZODB3 (at  least for  Jessie). Barry:  If persistent  = 4.0  Debian
package is useful on  its own to anyone (and thus  should not be removed
From testing),  then can I  add a Conflict  on both packages  and upload
them to fix this bug?

IIRC, I needed to update python-persistent for the Python 3 zope.component
transition, as it's a build-dep.  There are no other reverse dependencies that
I know of.

I think a Conflicts is the right way to handle this for now, given where we
are in the Jessie release cycle.  Arnaud, thanks for handling this!


signature.asc
Description: PGP signature
___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#768334: genshi: We now have what we need to re-enable genshi for Python 3.4

[Barry Warsaw]

Source: genshi
Version: Re-enable genshi support for Python 3.4
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

We previously had to deliberately disable python3-genshi support for
Python  3.3 because upstream was not compatible.  This was
implemented in the form of an ImportError raised when sys.version_info
indicated Python 3.4 or greater.  As Python 3.4 is the only available
version on Jessie, this renders python3-genshi useless.

Although upstream is quite slow to release new versions, their
upstream vcs has patches, and the Fedora genshi maintainer has
provided pointers to their packaging, both of which should allow us to
re-enable support for genshi in Python 3.4.  I'll be working on
packaging that up, and I intend to file an rc bug and request a freeze
exemption for Jessie once this is working.


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

Kernel: Linux 3.16-3-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

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJUW5N1AAoJEBJutWOnSwa/DRMP/1k7/7WD+1Vnryq+3Ar+N47x
wApT3vRRymW2/AHyt+4POMAjL2MiM6NylmpNIoie+miK2NgSrIo68BRzVJl07DGw
sp6T/VdelHUPIsKGMA64+4wFpTbt4qRcRhepaHnShNYxQRtidwJiwbKlGcutWc+h
K2/veka981cp+85LGqjB/bo0MqzU0Jz0nAJNOZ1UlcvX95TRZxvCqtyOGsb0uIfB
x/Ob+A84vRF7gOQrpAJUcdjk8kKRLr3roQ1VE9fZ7yUulmw/Tq6Bf/9SquGeej+x
21gIjj+BLpA0WIM0B4JltxyrDAmh2uVyJZ9ORhTX4wPqLVPjp8+hKbiOhB7VtZ4q
b9W8+UnBp1VetHnJ53ltRnjCimWvPnOS844FMU9BVVe1e7WtOrBCja7beqwHdHy6
pHjFJ9Nz8vZamPqcbn67GFsG37M1z87KCEooVjlw+Td4l8UBm47UEVGh3QHrSjGL
9KVLUXdlvDjAqOOltwcXXG9d8K4X/G+n9a/C+nEty8n3+kUL2SFT0cO3LvJ9CKKQ
/d58QzwFsG8UWQKBiiD1py8XgjaEidgA4ggiHTtnZNbOFkOQ09IBQQqvwsxghYCv
+kK7JubbQromF+5xGQ0g+9gkFdsPj6IX+zzotGb3tbUEyNItuGvLKbJq9dAkWcth
yZeWP8BiEWCVH0oxreno
=mOJM
-END PGP SIGNATURE-

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

Re: [Python-modules-team] Comments regarding python-pyramid_1.5.1+dfsg-1_amd64.changes

[Barry Warsaw]

On Jun 30, 2014, at 11:18 AM, Thorsten Alteholz wrote:

in debian/README.source you wrote that the docs directory has been 
removed. But it is still available in the source tarball. There might 
have gone something wrong ...

Hi Thorsten, thanks for the report.

I think this may be due to a strange interaction between svn-buildpackage,
which the Debian Python and Zope teams use, uscan's semi-documented
d/copyright Files-Excluded header, and weirdness/buggyness in the d/watch file
name manging.

You'll see in d/copyright that I added a Files-Excluded header to trim the
non-free docs/ directory, and in fact, when I watch the output of
svn-buildpackage, I can see that the tarball is downloaded and repacked
without the docs/ directory.

However, if you look closely, you'll find three tar.gz files in the various
resulting artifacts.

% find . -name \*.gz
./tarballs/python-pyramid_1.5.1.orig.tar.gz
./tarballs/python-pyramid_1.5.1+dfsg.orig.tar.gz
./build-area/python-pyramid_1.5.1+dfsg.orig.tar.gz

% tar ztvf tarballs/python-pyramid_1.5.1.orig.tar.gz | grep docs/ | wc -l
0
% tar ztvf tarballs/python-pyramid_1.5.1+dfsg.orig.tar.gz | grep docs/ | wc -l
777
% tar ztvf build-area/python-pyramid_1.5.1+dfsg.orig.tar.gz | grep docs/ | wc -l
777

svn-bp uses the build-area tarball, which is how the docs/ directory sneaked
back in.

What to do?

I suppose it would be best to reject the NEW python-pyramid package, and let
me rebuild the binary package after manually shuffling the repacked tar.gz
into place.  Otherwise, I won't be able to upload a correct tarball until the
next upstream release.  I have that fixed upload ready to go now.

If you have any suggestions on how to fix the d/watch file so this won't be a
problem in the future, please do let me know.  Otherwise I'll ping the
appropriate mailing lists for advice.

Cheers,
-Barry


signature.asc
Description: PGP signature
___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

Re: [Python-modules-team] Comments regarding python-pyramid_1.5.1+dfsg-1_amd64.changes

[Barry Warsaw]

On Jun 30, 2014, at 10:21 PM, Thorsten Alteholz wrote:

On Mon, 30 Jun 2014, Barry Warsaw wrote:
 I suppose it would be best to reject the NEW python-pyramid package,

ok, done

New version uploaded.  Hopefully I got it right this time.

Cheers,
-Barry


signature.asc
Description: PGP signature
___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

Re: [Python-modules-team] Comments regarding python-pyramid_1.5.1+dfsg-1_amd64.changes

[Barry Warsaw]

On Jun 30, 2014, at 10:21 PM, Thorsten Alteholz wrote:

On Mon, 30 Jun 2014, Barry Warsaw wrote:
 I suppose it would be best to reject the NEW python-pyramid package,

ok, done

Darn, the new upload was rejected.

On Jun 30, 2014, at 09:56 PM, Debian FTP Masters wrote:


python-pyramid_1.5.1+dfsg-1_amd64.changes is already known.


===

Please feel free to respond to this email if you don't understand why
your files were rejected, or if you upload new files which address our
concerns.


-Barry


signature.asc
Description: PGP signature
___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#736878: python-django: Please provide python3-django

[Barry Warsaw]

On Jun 17, 2014, at 08:52 AM, Raphael Hertzog wrote:

(CCing Barry who expressed interested in python3-django as well)

I started a *very* minimal branch for adding Python 3 packaging to
python-django 1.6, although 1.6.5 is the latest on PyPI (and in Debian).
There's really not much to my branch that can't be easily reproduced better
based on the current packaging.

For decent setup.py-based bilingual upstream projects, it's generally pretty
easy to add Python 3 support.  This wiki page has lots of good details:

https://wiki.debian.org/Python/LibraryStyleGuide

For pure libraries, there are tons of existing examples.  You can start with
most of the packages I'm maintaining in Debian:

http://qa.debian.org/developer.php?login=barrycomaint=yes

It can be a little trickier for packages that also contain executables,
because in general we don't want both Python 2 and Python 3 versions /usr/bin
scripts.  There are a few exceptions where the shebang line is meaningful, but
usually we just want /usr/bin to be shebang /usr/bin/python3.  Recent uploads
of mine for tox and virtualenv can serve as examples for these.

I have not yet converted any package to python 3 so I should look
up how to do it.

Indeed!  It's easy and fun. :)

I think the basic idea should be along this:

- enable dh_python3
- add binary package python3-django with the relevant files and binary
  dependencies

Also, adopt the pybuild build system.

One question where I don't have a clear answer is whether we should try
to put the code in some python-django-common package because otherwise
python3-django and python-django contain the same set of files just
in different directories (and with different dependencies). The answer is
probably yes because the package is relatively big... but then I don't
know of any Python package where the code lies in a dependency and where
the binary package just provides the byte-compiling glue for a specific
Python version.

Python source files should not be shared between the python- and python3-
(i.e. Python 2 and 3) stacks.  Each binary library package will have its own
copy of source files, but you *can* share source files for multiple versions
of Python 3.  pybuild mostly does this for you automatically.  You only have
to worry if e.g. something is Python 3.4 compatible but not Python 3.5
compatible.  Since Jessie is about to drop Python 3.3 any day now, and Python
3.5 is a *long* way off, you really only have to care about Python 2.7 and
3.4.  Still, your library should install into /usr/lib/python3 not
/usr/lib/python3.4.  pybuild has a few minor gotchas for some odd packages,
but you may not encounter it, and if you do, contact us on #debian-python or
debian-python@ so we can help you smooth those out.

Non-source files *should* be moved into a separate, common binary package.
Examples of these are data files, manpages, documentation, etc.  Depending on
the specifics of the package, I can help you figure out how to partition
things.  I also generally move executables to a separate binary package too.
Thus you might see some of these binary packages:

python-foo - the Python 2 library
python3-foo - the Python 3 library
{python-,}foo-common - common stuff like data files
{python-,}foo-bin - /usr/bin executable and manpages

There are lots of ways do it.  The only requirements are that the Python 2
library goes in python-foo and Python 3 library goes in python3-foo.

If anyone knows a sample package where we can get inspiration from, please
let us know.

See above.

Hope that helps!


signature.asc
Description: PGP signature
___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#732463: (no subject)

[Barry Warsaw]

easy_install isn't the right way to install packages into the virtualenv
anymore.  Please use pip, which should be installed in venv/bin
automatically now.  I cannot reproduce the traceback you're seeing.

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#744145: (no subject)

[Barry Warsaw]

I've not been able to reproduce this.  I find it strange that the requests
package didn't get installed automatically as a dependency.  In any case,
please try again with the upcoming pip 1.5.6 upload.

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#725848: (no subject)

[Barry Warsaw]

Switching to --user by default is being actively discussed upstream:

https://github.com/pypa/pip/issues/1668

In the meantime, I plan on updating the manpage to describe --user and any
other missing options.

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#748704: python-webob: lintian warnings

[Barry Warsaw]

Package: python-webob
Version: 1.3.1-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear Maintainer,

The source package generates a lintian warning

W: python-webob source: missing-license-paragraph-in-dep5-copyright
mit (paragraph at line 6)

I think this is because the debian/* files are licensed under MIT
but there is no License: MIT section in d/copyright.  debian/* is
probably intended to be licensed under the Expat license just like the
upstream files.  Since I'm not in the copyrights I won't changes this
myself, but it should be a trivial fix.

Perhaps while you're at it, this binary package lintian warning should
be fixed too.

W: python-webob-doc: extra-license-file
usr/share/doc/python-webob-doc/_sources/license.txt


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

Kernel: Linux 3.14-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

Versions of packages python-webob depends on:
ii  python  2.7.6-1
pn  python:any  none

python-webob recommends no packages.

Versions of packages python-webob suggests:
pn  python-webob-doc  none

- -- no debconf information

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJTemrBAAoJEBJutWOnSwa/5pQQAKBPumZf5/Ke4WEliA7SjhP4
1ijP1TI/0NGXsxh0o3DYAnOW/PCiPl3uXWwW+eOP0Mjskbc6/B/faFCvL4wqMATf
LnaSpkD9/LtYUoS9neXW1WpgFrBe+H05XhOVLAEEpv72HNu6mLiUoFAmgRF3zX0f
R2rUmghilzTR8pG7CCX4dyquR2j6Zf2qYRKHDs6Nb1RyGpwLIM85Kzs91zRlf0B8
nIkRhfQkduoTCY9S4Y2pEQdBBii5J8xJVF6v8fHzs3gDz8u4m4aNs6gfddOEyihz
uRNygR5dl5JhiaoprUp4V63LgVFMhUCzfMIhLFONstRrOLgVHcb9wA2cJionYJvw
pi9rQomUoZVYBsR+I17TYYifBV/tPNsaOTlP5LS2p3t7W+5erL3iHqlGBfgnIfhY
LbSYWrWs9R0rRYwQQx5UPRRNxr0D2OZrT9TCqtzPqbH44kfRGmX8sPK5n6xKlDgr
5ductBFY28QQ9UQ9ADBMu+SFbMPfB8lU3al052AvkAL+MIDx4Edk7s36UKh03L32
+wXl9nJi/dOyiy8QQM8ZEU5L8eIV8If7kyEMXoVuubGXvnHd1CwwDt6U3lsjQBtM
9M+G0qZOmtnTZiT4Vfdc33v6LWSQb5+GOIWTjSm9DTQRUmAW8oV1oaYIqnfoib9z
Hfu2rkD3LSTOaIHoePPp
=BHPu
-END PGP SIGNATURE-

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#719767: (no subject)

[Barry Warsaw]

Note that in Python 3.4, we have the stdlib ensurepip module which exposes the
exact same probably there.  See bug #732703 for details.  I am in the process
of uploading a Debian policy compliant solution, even though it's rather
complex.  The same solution could be shared by the standalone
python-virtualenv package.  Once #732703 is fixed, I'll look into porting that
code into python-virtualenv.

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#741291: python-psutil: Please update to psutil 2.0

[Barry Warsaw]

Source: python-psutil
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear Maintainer,

psutil 2.0.0 was just announced.

https://pypi.python.org/pypi/psutil/2.0.0

Please update to the new version.  There are some API changes, but it
seems easy to port to the new version.


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

Kernel: Linux 3.13-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

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJTHiFiAAoJEBJutWOnSwa/El0P/2ruZb6XY9uwROxoeSuNqvOl
TtAfGiQrapEIY1AxvP52Qekk7tec+ASxXPk+9hSzzNCLx0yUZScgPT9SmV6Qnc8K
j4MTJ3Z11OHbzUHEC3YGeJ4z/5P4ZjtE+mz8I/LD83eKBOMd6ybbGsLJVLbQghCu
8/PhkWmEV1zCxM84D/jYbO8IqiVOVOY/ibTfPPnEs8I5CyARHxbk2uLokHzkzQ9G
lgBA7CZAdQKPJYWlnrMFan4+8LlY53cPY5d11eVyhSsEDItyXxXGvEOk4yATQmN8
IL5r4n6ecyL4v+kyFs7ggN+OO0kbuZMhjWcp7sr/OHmLkk2WJso2WrN/NyF2DA9c
poIzUtLXitXSurl7VaqF073ArP/cXv7yB9IdjNG2/rdciEVyJY+Dac6PS/DdGhGO
rFLbK2i9WgBgPt8j7IQgDk8IH8E2G/YteFwad965Dp3N71VDNLk3dLqFSLWPwXzu
YS8FNdg7pB5D510Lb7PI1+qe/5RmfuUzroRt5wg1TzBqoKJHkgp99PPZAWYam1dO
MDWEs2iIEiOJ1nCZB5FFhnUWcc1TzmWYnJZgFFh0PV8vHyGkGHXxJiOeXXoYmQZq
edgQb5VjcZU/4KcJW3bsbG1qfgHFLyAihQ/5lueKIpqMunohLXuV6rgZyUO5ZaFO
zd6I8OL9+Td2e+TqcRUZ
=Qx81
-END PGP SIGNATURE-

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#732148: genshi: Rebuild docs at build time

[Barry Warsaw]

On Dec 16, 2013, at 12:41 PM, Arnaud Fontaine wrote:

 I see that you're shipping a -doc package, and it looks like
 you're not rebuilding docs from a quick scan of rules.

 Please re-build docs at build-time, don't ship pre-built
 output of sources.

Could you please elaborate?

Actually, this comment came from FTP Masters when they approved the
python3-genshi NEW package.  The source tarball comes with both generated
.html and source reST files (in .txt), so they want us to generate the .html
from the .txt files.  I took a quick look at it looks like there's a setup.py
command to do this, so that would just need to be integrated into d/rules.


signature.asc
Description: PGP signature
___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

Re: [Python-modules-team] Comments regarding genshi_0.7-1_amd64.changes

[Barry Warsaw]

On Dec 14, 2013, at 05:23 PM, Paul Richards Tagliamonte wrote:

I see that you're shipping a -doc package, and it looks like
you're not rebuilding docs from a quick scan of rules.

Please re-build docs at build-time, don't ship pre-built
output of sources.

Bug #732148

Cheers,
-Barry


signature.asc
Description: PGP signature
___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#731299: (no subject)

[Barry Warsaw]

I just updated svn for pytest 2.5.0, which depends on python-py 1.4.19.  I
updated the d/control version dependency as per this bug.

python-py's maintainer has just uploaded 1.4.19 so we should wait on uploading
pytest 2.5.0 until that's landed.

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#729061: python-psutil: New upstream version 1.1.3

[Barry Warsaw]

Package: python-psutil
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear Maintainer,

There's a new upstream version available (1.1.3 as of this writing).
It should be as easy as bumping d/changelog.  I've tested it locally
and it seems fine.


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

Kernel: Linux 3.11-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

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

iQIcBAEBCAAGBQJSfN4sAAoJEBJutWOnSwa/KE8QAJM1P4D5myM5zWSz9HvPWpbX
VuwQcwBlGcAGcW+T9CN9dd4QNPy7JPhM4wlNi6bXlHQ48hGvzc9liYjgnVbt2MzM
iV7H0gl342KtoS5PgIDLZ01HxV9DZz+356J0e3covVcVLS4JBZjX86m0O3KBwJPH
hiwQ3e0h7NSBohOPirJvWM1nJmUcyQaSqbpjQkmu9QAmkvqwCaIwJeD/QuMO60LS
HZnoL1CR6OCrloOKKNG+DzKIsWIw5DPg/L0VceVyJzbb2cbBazz0kUBUipUWbZld
Uj5dOW1uhj9R8tV3OrGktCVod2viIxZ5FT+wdAR41YFmTbGZf9zJGX9GLBqXsHA2
d9oWa3ywMvLZJGFiPuEVQ98luxS0+CGTRlN4IreSzJjh68Vxc8LfUKlI2p4e5nBn
GKOs3dwGxZFsYCv2BMvajAh+FhKflMD91CjoNriXbuojYe4r7uCyrOq3xDs4/HV9
d3jQRZ5ypkN4e81XwXlyDIIS2ZIJX9Mn8gFRL75+Db0Y5+x4WSupggups2jXcXo4
66Gr33m1SP8hsKjcT1YOm300lbjj7eHdtqNyd81LGw6/RWQBt5o5fhgDFb6hOvvv
AeYpTfD/eS3hCCg5E+KU7rT4W1IA9EuZVOc7U8aimrO9hqnlT2gVk2JlR6ugtaKm
AAvnr9DlDV26jpCWQ9pj
=MQPz
-END PGP SIGNATURE-

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#722295: python-pip: ca-certificates needs to be Depends rather than Recommends

[Barry Warsaw]

Package: python-pip
Version: 1.4.1-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear Maintainer,

Since SSL certificate checks are now on by default, we really need
ca-certificates to be available for pip to be functional.  I propose
to move it from Recommends to Depends.


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

Kernel: Linux 3.10-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

Versions of packages python-pip depends on:
ii  python2.7.5-4
ii  python-pkg-resources  0.6.49-2
ii  python-setuptools 0.6.49-2

Versions of packages python-pip recommends:
ii  build-essential  11.6
ii  ca-certificates  20130906
pn  python-dev-all   none

python-pip suggests no packages.

- -- no debconf information

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

iQIcBAEBCAAGBQJSLj7WAAoJEBJutWOnSwa/HzUQALz6w+GqzCrHlplMq9oXtcmi
L7PCEkC95T7k9dYQRMmixNAhWJq7/J4eznydZNj5RZqcm/28YCYBu0YLC+rG5cj2
UaveZXs30Dt2mjReZLsb9uWBjQec9d+7Vk2q80TQ+5ab2aERH9TdYdkLi6Nw4iWN
+7Mduqb/InWKCZmdc+ZWooDGT4/1CfiLAUVzBrATgH+EVvXyPhSJl//tfRaMq5lH
UMbijAcPnQjM891vb6wCXaS9Md5HQtYQP/SkwoWGLZwM6Wn+4UEXBp9sQJB+u7cw
IJoZn0gjl9sOAEbfRY/pwJ/IDmxWn5LNvX5/y3DsMQj/0905nx90T299ot8NfcW4
YV8RNnQtDY+5PJDFEuJ9/WLiZNoDJZC0kjFhCPQKoRK0I0fXSSJwlyDrgutFOvJj
yYNwKmC6DEkgKqj/3KCL9GRBLSJ1HI2WyBkLxak5Yd5LEMhv6eotOAi0KAQxeNZW
8a/OqFmxFATJhzxBuWGUzGJmiZKLKQLxK4lTE6JIkFLy+Lsk2iFL+J4nrS8WOYgG
/6HWFowKuMlzdNm6fVJK9TXStVmkpJkbR+U80X2y3/YZdC6ZA2kWZwHDyBKErOLG
niv0R7g1Z0/qwxWvKnesdhc2EH7/MfN1sIo2nZRhxqiPub4zS93IX/LKil0VwQi9
hM31CM88gsXg6DtjDm2+
=gVfF
-END PGP SIGNATURE-

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

Re: [Python-modules-team] Comments regarding python-webob_1.2.3-3_amd64.changes

[Barry Warsaw]

On Jul 27, 2013, at 11:42 PM, Paul Richards Tagliamonte wrote:

Heyya Barry,

The correct term for that license is `Expat', it'd be nice to change that
in d/copyright!

I changed that in svn for the `Files: *` and License section, but not for
`Files: debian/*` section.  I didn't want to do that without approval of the
other copyright holders for the packaging bits.  Cc'd here for feedback.

(Also, Uploaders: let me know if you mind me adding myself to the copyright
for debian/*)

-Barry



signature.asc
Description: PGP signature
___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#699312: (no subject)

[Barry Warsaw]

Please consider uploading pytest 2.3.4 to experimental soonish.  I would like
to update tox to 1.3.4, but this is blocked on a newer pytest.  I've updated
alioth pytest svn to the new version, but it currently ftbfs.

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#692602: python3-requests: Upgrade to new upstream version 0.14.2

[Barry Warsaw]

Package: python3-requests
Version: 0.12.1-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear Maintainer,

Latest upstream version on PyPI is 0.14.2.

I am in the process of upgrading the Ubuntu 13.04 version of the
package (LP: #1076107) and will add a patch when that's uploaded.


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

Kernel: Linux 3.2.0-4-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

Versions of packages python3-requests depends on:
ii  ca-certificates  20120623
ii  python3  3.2.3-5
ii  python3-six  1.1.0-2

Versions of packages python3-requests recommends:
ii  python3-chardet  2.0.1-1

python3-requests suggests no packages.

- -- no debconf information

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

iQIcBAEBCAAGBQJQmru8AAoJEBJutWOnSwa/OWEQAIJm3XChfiI9TOHc+sMNVSsX
w6OnfMfKtPxax2mPx8DIW5qkakJTxKLyhMmBXjzXzYwiOuJRpB5EyukzKBTGirX5
eWpMrQeYM20cGqaYqyzKDYiwp8k9rWBIfNEjawfW+QG4YxFTtO+IbokocsSMPAwD
LCYV9WTfCSnjAGN7qkPI8kI/umcFp6BS5CjTQ45/gdJSKlgfYLOcuCvecdo0TN3N
OE5BVgk6muMW8sF11Cb7yS+CNsq/oTBABzx/iuRtQZjLM1D/CvrbGspNZVsmGJw7
fBUE7830NSFzcD11FxNbpdPLQtE4Z1PqP4AjN4/AhfHrxOjuETFMsn6h/bb5yPlt
nUXNhSlEtSRQqFHMtgVyOH1viYYo21SYW2QozQN9GH5f8gLXSVU3lmHY1wS1uXII
jWaKhRjUILMBmLAZp5G3h4dU7qFWgPsyGWNKYSPScHWrXw/JOj5+x9c0FojwyT7V
6Y/tD/s7oua+nRAg+PLsWj/2fox55yF6ViJbERihkieFcuf7i5vswS9peKARD+yj
ClMtdnKZqVgJlBRwMZ+mwTZ74GfTNERaGlIKlVKYpr9o9NqsWnQDquTILaKSE5CA
z1qSHO/p9T6F6fYOjML+GVPRAzm+6l1osdsx2Qw/ewA2/IWvvkwxQJN8XC2K4yMu
yqW1H4lO7LBtA5/8mIKw
=jXcf
-END PGP SIGNATURE-

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#692602: (no subject)

[Barry Warsaw]

Attached is the diff against the Ubuntu version of the package.  You should be
able to extract the relevant changes for the Debian version, but because you
might be interested in our delta from Debian, I'm including the entire diff.
If not, let me know and I can prepare a diff just for the Debian version.

=== modified file 'debian/changelog'
--- debian/changelog	2012-09-13 14:55:21 +
+++ debian/changelog	2012-11-07 20:11:05 +
@@ -1,3 +1,15 @@
+requests (0.14.2-0ubuntu1) raring; urgency=low
+
+  * New upstream release (LP: #1076107).  Remaining changes:
+- debian/patches/01_do-not-use-python-certifi.patch: No longer necessary.
+- debian/patches/02_do-not-use-embedded-python-six.patch: refreshed
+- debian/patches/03-dont-use-embeded-urllib3.patch: refreshed and
+  renamed to 03-use-distro-packages.patch
+- debian/control: python-chardet and python3-chardet are now required
+  (i.e. Depends instead of Recommends).
+
+ -- Barry Warsaw ba...@ubuntu.com  Thu, 01 Nov 2012 14:56:00 +0100
+
 requests (0.12.1-1ubuntu6) quantal; urgency=low
 
   * debian/control: Resolve Depends misspelling of python-urllib3. 

=== modified file 'debian/control'
--- debian/control	2012-09-13 14:55:21 +
+++ debian/control	2012-11-07 19:46:11 +
@@ -11,6 +11,7 @@
  python3-all,
  python3-six,
  python-chardet,
+ python3-chardet,
  python-urllib3,
  python3-urllib3,
  python-gevent,
@@ -30,9 +31,9 @@
  ${python:Depends},
  ca-certificates,
  python-urllib3,
- python-six
+ python-six,
+ python-chardet
 Recommends:
- python-chardet,
  python-gevent,
  python-oauthlib
 Description: elegant and simple HTTP library for Python, built for human beings
@@ -61,8 +62,7 @@
  ${python3:Depends},
  ca-certificates,
  python3-urllib3,
- python3-six
-Recommends:
+ python3-six,
  python3-chardet
 Description: elegant and simple HTTP library for Python3, built for human beings
  Requests allow you to send HTTP/1.1 requests. You can add headers, form data,

=== removed file 'debian/patches/01_do-not-use-python-certifi.patch'
--- debian/patches/01_do-not-use-python-certifi.patch	2012-05-04 14:34:47 +
+++ debian/patches/01_do-not-use-python-certifi.patch	1970-01-01 00:00:00 +
@@ -1,17 +0,0 @@
-Description: To verify SSL certificates for HTTPS requests, use the bundle
- provided by ca-certificates instead of python-certifi.
-Author: Daniele Tricoli er...@mornie.org
-Forwarded: not-needed
-Last-Update: 2012-05-04
-
 a/setup.py
-+++ b/setup.py
-@@ -32,7 +32,7 @@
- # On certain supported platforms (e.g., Red Hat / Debian / FreeBSD), Requests can
- # use the system CA bundle instead; see `requests.utils` for details.
- # If your platform is supported, set `requires` to [] instead:
--requires = ['certifi=0.0.7']
-+requires = []
-
- # chardet is used to optimally guess the encodings of pages that don't declare one.
- # At this time, chardet is not a required dependency. However, it's sufficiently

=== modified file 'debian/patches/02_do-not-use-embedded-python-six.patch'
--- debian/patches/02_do-not-use-embedded-python-six.patch	2012-04-01 12:33:42 +
+++ debian/patches/02_do-not-use-embedded-python-six.patch	2012-11-01 14:03:01 +
@@ -5,45 +5,47 @@
 
 --- a/requests/packages/urllib3/connectionpool.py
 +++ b/requests/packages/urllib3/connectionpool.py
-@@ -51,7 +51,7 @@
+@@ -52,7 +52,7 @@
  )
-
+ 
  from .packages.ssl_match_hostname import match_hostname, CertificateError
 -from .packages import six
 +import six
-
-
+ 
+ 
  xrange = six.moves.xrange
 --- a/requests/packages/urllib3/filepost.py
 +++ b/requests/packages/urllib3/filepost.py
-@@ -14,8 +14,8 @@
-
+@@ -10,8 +10,8 @@
+ from uuid import uuid4
  from io import BytesIO
-
+ 
 -from .packages import six
 -from .packages.six import b
 +import six
 +from six import b
-
+ 
  writer = codecs.lookup('utf-8')[3]
-
+ 
 --- a/requests/packages/urllib3/response.py
 +++ b/requests/packages/urllib3/response.py
 @@ -11,7 +11,7 @@
  from io import BytesIO
-
- from .exceptions import HTTPError
+ 
+ from .exceptions import DecodeError
 -from .packages.six import string_types as basestring
 +from six import string_types as basestring
-
-
+ 
+ 
  log = logging.getLogger(__name__)
 --- a/requests/packages/urllib3/util.py
 +++ b/requests/packages/urllib3/util.py
-@@ -16,7 +16,7 @@
+@@ -18,7 +18,7 @@
  except ImportError: # `select` doesn't exist on AppEngine.
  select = False
-
+ 
 -from .packages import six
 +import six
  from .exceptions import LocationParseError
+ 
+ 

=== removed file 'debian/patches/03-dont-use-embeded-urllib3.patch'
--- debian/patches/03-dont-use-embeded-urllib3.patch	2012-09-07 09:06:26 +
+++ debian/patches/03-dont-use-embeded-urllib3.patch	1970-01-01 00:00:00 +
@@ -1,60 +0,0 @@
-Description: Do not use embeded copy of python-urllib3
-Author: Chuck Short zul...@ubuntu.com
-Forwarded: non-need
-Last-Update: 2012-09-05
-diff -Naurp requests-0.12.1.orig/requests/models.py requests-0.12.1/requests/models.py
 requests-0.12.1

[Python-modules-team] Bug#692602:

[Barry Warsaw]

On Nov 08, 2012, at 12:04 AM, Daniele Tricoli wrote:

Hello Barry,

On Wednesday 07 November 2012 21:18:27 Barry Warsaw wrote:
 Attached is the diff against the Ubuntu version of the package.  You
 should be able to extract the relevant changes for the Debian version,
 but because you might be interested in our delta from Debian, I'm
 including the entire diff. If not, let me know and I can prepare a diff
 just for the Debian version.

Many thanks for your work! I followed the Ubuntu bug but I was a litte busy
so your patch arrives in a perfect time.  I don't intend to diverge for your
work, but I think I will able to use this entire diff.

Due to the freeze I will ask for an upload on experimental. Is this a 
problem for Ubuntu?

For the bug tracker (since we chatted on IRC): this is perfect.  I'll resync
when the upload lands in experimental.

Tell me if I can do more. Many thanks and kind regards,

Perfect, and thanks!  Although I forgot to file a bug on it, I also updated to
the latest upstream of python-urllib3 (1.5).  We did have to add a few patches
to that package, but it would be great to also get that updated in Debian
too.  Since you're the maintainer of that package too, will you grab the
Ubuntu (raring) version for experimental, or would you like me to file a
separate bug on that?



signature.asc
Description: PGP signature
___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#669301: pyopenssl: Build the Python 3 version of the package

[Barry Warsaw]

Package: pyopenssl
Version: 0.13-1
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear Maintainer,

Upstream pyOpenSSL supports Python 3.2 as described here:

http://pypi.python.org/pypi/pyOpenSSL/0.13

This patch enhances the packaging to build and install the Python 3 versions
of the package (normal and debug).

Thank you for your consideration.

- -- System Information:
Debian Release: wheezy/sid
  APT prefers precise-updates
  APT policy: (500, 'precise-updates'), (500, 'precise-security'), (500, 
'precise'), (100, 'precise-backports')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-23-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

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

iQIbBAEBCAAGBQJPjyq8AAoJEBJutWOnSwa/tFgP90Cy9D07zDu7ooibz/1dYamc
ykBG8JAbYQCAI7VT503rLezz7WPRjjVE4Bl6tUaUNLxIr2hrXTmpQLAWA1qZMIw2
MvgWV3J5KtzTYHtoaOlvDNIEIjUKqsAiPq5ZoYTs54yWF7Mq7Sb1oORnUAFQmLqS
6LiUsl6Ar3z0gPbLfdxyTce1y78CveYs7nygGCIXkRUDlk81VAzThzCdWXnDjHS9
GCEdXVjs9ms40RAp1zUKfutKU43bd2cGPOxxAufUxcpeHclweIE10+d5ZCZC6Yeg
KJzLHM7jf6KiIv9tg4G/QU0qwbv/OQZVL/4EgXXytBDS8y7UMr6eruXJoNiaixHn
IiBLwRIs+MQr/g6wyVeHH7vZo8vHI6VikK/NKNgZM8w9hNyT1HJPncdQuAYw9vHm
l5hjm9JP3prpJpzXkUTXAS+g7iXzl4pyZifrV2GwXMiMXn8LtNXFvDVsqTj/++3f
L7sGfoJl1w6rfcJNogLl8TaJpvtPzPVr2nfEzhTEgb5k81MoYa5qKqhbF+3MDhPP
nyrt+4PJQcbuKPRYvXKgVxfsNvTnZfm7o5t8mAvH8WCxX/wIKvoFs9F/M5xCEBpb
o+FlZlpCK0M6487lYKi71a+GzOZVtSu8cYllvZE8FKY8D4CMES/ZfmgjrxWR6BP6
MK5Egx+pHcmy4SbW+ug=
=cOKE
-END PGP SIGNATURE-
=== modified file 'debian/changelog'
--- debian/changelog	2011-09-11 16:46:29 +
+++ debian/changelog	2012-04-18 19:07:59 +
@@ -1,3 +1,9 @@
+pyopenssl (0.13-2) UNRELEASED; urgency=low
+
+  * Enable the Python 3 version of the package.
+
+ -- Barry Warsaw ba...@python.org  Wed, 18 Apr 2012 15:07:31 -0400
+
 pyopenssl (0.13-1) unstable; urgency=low
 
   * New upstream release

=== modified file 'debian/control'
--- debian/control	2011-08-15 18:44:39 +
+++ debian/control	2012-04-18 19:39:17 +
@@ -3,18 +3,19 @@
 Priority: optional
 Maintainer: Debian Python Modules Team python-modules-team@lists.alioth.debian.org
 Uploaders: Sandro Tosi mo...@debian.org
-Build-Depends: debhelper (= 5.0.37.2), python-all-dev (= 2.5.4-1~), python-all-dbg (= 2.5.4-1~), python-support (= 0.6.4), libssl-dev (= 0.9.8), tex4ht, w3m, texlive-latex-base, texlive-latex-recommended, openssl
+Build-Depends: debhelper (= 5.0.37.2), python-all-dev (= 2.5.4-1~), python-all-dbg (= 2.5.4-1~), python3-all-dev, python3-all-dbg, python-support (= 0.6.4), libssl-dev (= 0.9.8), tex4ht, w3m, texlive-latex-base, texlive-latex-recommended, openssl
 Standards-Version: 3.9.2
 Homepage: http://launchpad.net/pyopenssl
 Vcs-Svn: svn://svn.debian.org/python-modules/packages/pyopenssl/trunk/
 Vcs-Browser: http://svn.debian.org/viewsvn/python-modules/packages/pyopenssl/trunk/
 XS-Python-Version: all
+X-Python3-Version: = 3.2
 
 Package: python-openssl
 Architecture: any
 Depends: ${python:Depends}, ${shlibs:Depends}, ${misc:Depends}
 Suggests: python-openssl-doc, python-openssl-dbg
-Description: Python wrapper around the OpenSSL library
+Description: Python 2 wrapper around the OpenSSL library
  High-level wrapper around a subset of the OpenSSL library, includes
  .
* SSL.Connection objects, wrapping the methods of Python's portable
@@ -30,7 +31,7 @@
 Section: doc
 Architecture: all
 Depends: ${misc:Depends}
-Suggests: python-openssl
+Suggests: python-openssl, python3-openssl
 Description: Python wrapper around the OpenSSL library (documentation package)
  High-level wrapper around a subset of the OpenSSL library, includes
  .
@@ -50,16 +51,52 @@
 Section: debug
 Architecture: any
 Depends: ${misc:Depends}, python-openssl (= ${binary:Version}), python-dbg, ${shlibs:Depends}
-Description: Python wrapper around the OpenSSL library (debug extension)
- High-level wrapper around a subset of the OpenSSL library, includes
- .
-   * SSL.Connection objects, wrapping the methods of Python's portable
- sockets
-   * Callbacks written in Python
-   * Extensive error-handling mechanism, mirroring OpenSSL's error
- codes
- .
- A lot of the object methods do nothing more than calling a
- corresponding function in the OpenSSL library.
- .
- This package contains the debug extension for python-openssl.
+Description: Python 2 wrapper around the OpenSSL library (debug extension)
+ High-level wrapper around a subset of the OpenSSL library, includes
+ .
+   * SSL.Connection objects, wrapping the methods of Python's portable
+ sockets
+   * Callbacks written in Python
+   * Extensive error-handling mechanism, mirroring OpenSSL's error
+ codes
+ .
+ A lot of the object methods do nothing more than calling a
+ corresponding function in the OpenSSL library.
+ .
+ This package contains the debug extension for python-openssl.
+
+Package: python3-openssl
+Architecture: any
+Depends: ${python3

[Python-modules-team] Bug#658787: (no subject)

[Barry Warsaw]

I noticed this same failure when I tried to build the package for Ubuntu.
However, what was weird was that it succeeded for amd64 but failed for i386.

https://launchpad.net/ubuntu/+source/cssutils/0.9.8-1build1

Same results in my PPA:

https://launchpad.net/~barry/+archive/python/+packages

I *think* the external access is mocked in the test suite, so in theory it
shouldn't cause a failure.  For some reason this doesn't work correctly for
i386, but does for amd64 (where the tests all pass in the buildds).

It would be interesting to know whether Debian sees the same behavior, and
whether a better fix than just disabling all the tests exists.  It might also
be worth looking at cssutils 0.9.9 (which is available on PyPI at the time of
this writing).


signature.asc
Description: PGP signature
___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#658787: (no subject)

[Barry Warsaw]

Duh.  arch: all so nevermind.


signature.asc
Description: PGP signature
___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#637382: python-psutil: Switch to dh_python2

[Barry Warsaw]

Package: python-psutil
Version: 0.2.1-1
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu oneiric ubuntu-patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi Sandro.  This patch switches python-psutil to dh_python2.

Cheers.

*** /tmp/tmpEEDKld
In Ubuntu, the attached patch was applied to achieve the following:


  * Switch to dh_python2. (LP: #788514)


Thanks for considering the patch.


- -- System Information:
Debian Release: wheezy/sid
  APT prefers oneiric-updates
  APT policy: (500, 'oneiric-updates'), (500, 'oneiric-security'), (500, 
'oneiric'), (100, 'oneiric-backports')
Architecture: amd64 (x86_64)

Kernel: Linux 3.0.0-8-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

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

iQIcBAEBCAAGBQJOQtKSAAoJEBJutWOnSwa/ywQP/AzXT/dg9d0oqPbY2FL9aweD
MMklVWuifLnMq/VQ4N4zCgD4702qmHBdCRi0YTYSxMcSmzq/jsywh/ERwo4sNiCj
9eC4YFziz3OmDTyLLX1vBXRTRH+khqFEdGTAmBK/Kv8kKlEga7U1MY0h8ua3BzaM
MEDDq2QWvYECeYb1kYSZeXijnS7kHAYOGxYvVsfQm3/WATPNfVI5aGwsyQTxoaVP
rcKLJVIa/sKTqoeKjtxFX2Edi+oIxyzojYUJollLnMPAb+DciTpXQskQDxZC4swg
Tgy+zMQXxGyBzSVd3mjZFlM8v5E3vEj8O2Yt0zg/LCGUCsedp7gXMcjHjHrBwlMN
SOdeZBd8QAA40XiC/dW2723r9+rCfaXBoC7Pm3XLNqsR8ZVga3xKyCrBVC3sdmex
PA9G87tAnZQDrDnWsMEganeRl3QgZWVBYsDPPR/aTTJmyTqXDhcOX3a0TOn0r2ft
toOQMgroKEEAw97JbZeOMDCT5mR4le4moMy+s6mPaE9rm7vs0Zxa2rT1IgCtnF8x
xutqegzVrUEvtxkN2AwR5NrOkgwjI9Ud2U3oIhk45Vw3AD1aslN+iaYxI0N3OxZb
Iu1VozuGRUIaUiC9XVfcO2woJB2n6UuFoc5mkqwempMm//XxvoJHi4N9fbRXvwtU
3qdwWtGKSu39Cz0zBDzw
=/Wig
-END PGP SIGNATURE-
=== modified file 'debian/changelog'

=== modified file 'debian/control'
--- debian/control  2011-04-04 20:26:42 +
+++ debian/control  2011-08-10 18:37:33 +
@@ -3,9 +3,8 @@
 Priority: optional
 Maintainer: Debian Python Modules Team 
python-modules-team@lists.alioth.debian.org
 Uploaders: Sandro Tosi mo...@debian.org
-Build-Depends: debhelper (= 7.2.18), python-all-dev, python-support (= 
1.0.0), procps
+Build-Depends: debhelper (= 7.2.18), python-all-dev (= 2.6.6-3~), procps
 Standards-Version: 3.9.1
-XS-Python-Version: all
 Homepage: http://code.google.com/p/psutil/
 Vcs-Svn: svn://svn.debian.org/python-modules/packages/python-psutil/trunk/
 Vcs-Browser: 
http://svn.debian.org/viewsvn/python-modules/packages/python-psutil/trunk/

=== modified file 'debian/rules'
--- debian/rules2011-04-04 20:26:42 +
+++ debian/rules2011-08-10 18:37:48 +
@@ -3,7 +3,7 @@
 PYVERS:=$(shell pyversions -s)
 
 %:
-   dh $@
+   dh $@ --with python2
 
 build:
dh build

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#634860: (no subject)

[Barry Warsaw]

Updated svn in r17925, including Breaks.  ScottK is going to review and upload.


signature.asc
Description: PGP signature
___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#635633: pyicu: Switch to dh_python2

[Barry Warsaw]

Package: pyicu
Version: 1.1-1
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu oneiric ubuntu-patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

python-support is now officially deprecated in Debian:

http://article.gmane.org/gmane.linux.debian.devel.python/6948

In Ubuntu, we are removing python-support from our CDs.  As part of this work,
I have converted pyicu to dh_python2 according to these guidelines:

http://wiki.debian.org/Python/TransitionToDHPython2

Please consider applying this patch to Debian so that we can sync the update
to Ubuntu.


*** /tmp/tmpx428Q4
In Ubuntu, the attached patch was applied to achieve the following:


  * Switch to dh_python2. (LP: #788514)


Thanks for considering the patch.


- -- System Information:
Debian Release: wheezy/sid
  APT prefers oneiric-updates
  APT policy: (500, 'oneiric-updates'), (500, 'oneiric-security'), (500, 
'oneiric'), (100, 'oneiric-backports')
Architecture: amd64 (x86_64)

Kernel: Linux 3.0.0-7-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

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

iQIcBAEBCAAGBQJOMFz7AAoJEBJutWOnSwa/w/cP/jYOW/JVrz6Vo2xJs9Uft2Q/
XMnHR7Ck/vS2QXmCc6jFNkfVBKKvllkM5SqBOUqumZ+ey0bOYVYzKKeXNQBkAaqv
NSThdJAL13iz0Uc4Tb/cq+vefIVsNPEdnf2vwVZTtii/AfUBLCsEaPfPUus7BtvZ
THhuCgGJc3w+8KALB6sqDM8CFj9AuriHH/dfDINv8cO0PBss34Ai9l9+dk3juzJ2
ZyNS3CeyXBKrQ+2QTg4w0GNhcP+FgRdAIOipOPHdsLsV5F8BbheP6IWF4/KJ7nPa
T02EE7fAlGmayVI+XBeHwrhXvRLENcPOfr+V1j8d2nVlSbC38v+pSynoB9qgYLpY
0ZOyvBH2S3fCRWxI2/3yguco2yugWB5bLyOqaXrAww1nacCLn93kiTVyuoKnyXvs
Hog8DTSEnuHTE9SCQ7zDoxlvUZEZ1Aowm7CVwDAB+1VGzLuQjs+zh6qpwDE6oEjV
gwooh3wyl/VgCgLU4ucZrZQaFQejmbzAvOeN0p1X0HIPVdM7gbHETH75JkNcHqir
obEIKAdln2QIuQTaFX8k4ig0LurAmXg+YJu1ttBAkGEPOA0KMOpgsTKDPD/1YD8F
7t7HpLjt39ipXDRMCkdbiz6nwjUgw/3nKLGft2KdUO2WY0skyWjSk/xpVoQonvaO
UqHVrk/HtbqGkTfg1PKn
=T0bU
-END PGP SIGNATURE-
=== modified file 'debian/changelog'

=== modified file 'debian/control'
--- debian/control  2010-06-22 20:59:32 +
+++ debian/control  2011-07-27 18:32:24 +
@@ -3,12 +3,13 @@
 Priority: optional
 Maintainer: Debian Python Modules Team 
python-modules-team@lists.alioth.debian.org
 Uploaders: Bernd Zeimetz b...@debian.org
-Build-Depends: dpatch, debhelper (= 5.0.37.3), python-all-dev (= 2.4.4-3), 
python-all-dbg (= 2.4.4-3), python-support (= 0.4), libicu-dev
+Build-Depends: dpatch, debhelper (= 5.0.37.3), python-all-dev (= 2.6.6-3~), 
python-all-dbg (= 2.6.6-3~), libicu-dev
 Build-Conflicts: python-pyicu
 Vcs-Svn: svn://svn.debian.org/python-modules/packages/pyicu/trunk/
 Vcs-Browser: http://svn.debian.org/viewsvn/python-modules/packages/pyicu/trunk/
 Homepage: http://pyicu.osafoundation.org/
 Standards-Version: 3.8.3
+X-Python-Version: = 2.5
 
 Package: python-pyicu
 Architecture: any

=== removed file 'debian/pyversions'
--- debian/pyversions   2007-12-06 22:45:38 +
+++ debian/pyversions   1970-01-01 00:00:00 +
@@ -1 +0,0 @@
-2.5-

=== modified file 'debian/rules'
--- debian/rules2011-02-14 13:15:13 +
+++ debian/rules2011-07-27 18:33:05 +
@@ -82,7 +82,7 @@
dh_compress -X.py
dh_strip -p$(PKGNAME) --dbg-package=$(PKGNAME)-dbg
dh_fixperms
-   dh_pysupport
+   dh_python2
rm -rf debian/$(PKGNAME)-dbg/usr/share/doc/$(PKGNAME)-dbg
ln -s $(PKGNAME) debian/$(PKGNAME)-dbg/usr/share/doc/$(PKGNAME)-dbg
dh_installdeb

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#616858: libapache2-mod-python: Patch to switch to dh_python2, and other fixes.

[Barry Warsaw]

On Jul 20, 2011, at 11:05 PM, Jakub Wilk wrote:

* Barry Warsaw ba...@python.org, 2011-07-20, 16:18:
Also note that with the current rules file mod_python does not seem to be 
buildable with more than one version of Python, so in converting to 
dh_python2, I set X-Python-Version: = 2.7.

Err, no, whatever you wanted to achieve, this is wrong.

The problem is that the package used to be doing

./configure --with-python-version 2.7

(admittedly, on Ubuntu, sorry ;)

but that does not work because the configure script does not recognize
--with-python-version.  The build log clearly warns about that.  So it really
wants to be

--with-python python2.7

But note also that --with-python does not accept a list of Python binaries,
and afaict, the rules file does not loop over multiple Python versions.  This
essentially mans libapache2-mod-python can only be built for one version of
Python (well, without more radical changes to debian/rules).

Maybe it's better to not include an X-Python-Version header and use

PYVER=$(shell pyversions -d)

instead?

Cheers,
-Barry


signature.asc
Description: PGP signature
___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#616858: libapache2-mod-python: Patch to switch to dh_python2, and other fixes.

[Barry Warsaw]

On Jul 20, 2011, at 05:16 PM, Barry Warsaw wrote:

Maybe it's better to not include an X-Python-Version header and use

PYVER=$(shell pyversions -d)

instead?

Close.  If you remove the X-Python-Version header, you need to add
--no-guessing-versions to the dh_python2 call.

Cheers,
-Barry


signature.asc
Description: PGP signature
___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#616858: libapache2-mod-python: Patch to switch to dh_python2, and other fixes.

[Barry Warsaw]

Package: libapache2-mod-python
Version: 3.3.1-9
Followup-For: Bug #616858
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu oneiric ubuntu-patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

As the bug report states, python-central is officially deprecated.  This patch
completes the switch, and also fixes a problem with the ./configure line.
configure does not accept --with-python-version but it does have a
- --with-python option which takes the Python binary name (e.g. python2.7).
This is why I changed PYVER to use `pyversions -r`.

Also note that with the current rules file mod_python does not seem to be
buildable with more than one version of Python, so in converting to
dh_python2, I set X-Python-Version: = 2.7.  Since Python 2.6 is the default
in Debian you'll probably want to change this (Python 2.7 is default in
Ubuntu, which is where I am going to upload this change).

I'm eager to hear back from you!  I hope you will consider this patch.

Thanks.


*** /tmp/tmpNLMMih
In Ubuntu, the attached patch was applied to achieve the following:


  * Switch to dh_python2.  (LP: #788514)


Thanks for considering the patch.


- -- System Information:
Debian Release: wheezy/sid
  APT prefers oneiric-updates
  APT policy: (500, 'oneiric-updates'), (500, 'oneiric-security'), (500, 
'oneiric'), (100, 'oneiric-backports')
Architecture: amd64 (x86_64)

Kernel: Linux 3.0.0-5-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

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

iQIcBAEBCAAGBQJOJzgcAAoJEBJutWOnSwa/XlgQAJj2PIuHrLkinex21g/OfSZ9
yCFy/BxJhKPFXirunNH0ZlIrHVQEqY5GMUYlQLpVnSc54MOZmKvm0/0P0U62GFi1
cmoBBwsKrScUNDa3aLRQh4qPCDmxaHN8xRhznmUPRSv3alrRruscO3KDmu1Q5cIZ
LwAgqSNqVXUIU4V0BqaGnLuGlBF+oBfZ03ph2J5g/j1uDy2BtcshIOgBHMOmSyGU
ow0KRhxS1mXQIR2YbgVhQ0PYXwuo6IvdCpJ5dgLekSvAqo+HA/2ZrDBMbyWyInKf
y7XHAjcW4CTc2oyg0SOf2Isl+Zu9xnOThXwQpCs0cyUOTlqX5VkWv8XRUaTEdrVA
qAcT7tRgIA9brnxz2vUcNHsWKYBZnQ2e+RgkuyQXs2EMi+sUU599Qaj8J33AEG51
4AGFck/xaBsuNY0SNeOXXPFS+g9d/toIacm7ShzyyNg8JbNlXXKOfM2ZODQYuYZV
g9kfEb8NkKMAGkMYFQr3eitfjtp0RUqzftjreg9Br/+uMpWLoyBehcT9a6S25uky
RmEovu7AyMqZrkEvz71fKa+Wn+8KLqBiPlKZFsewA71mHInch7eoXJsyI0OfbqBv
SK4zeaiDRi4aQ+m/jn4J3chUelFqBqhhR60QhY5xfqbq5erB9xbxnjv5sVBKvkPi
AnJPH4IUFfMNIOMW9FFx
=K9Qh
-END PGP SIGNATURE-
=== modified file 'debian/changelog'

=== modified file 'debian/control'
--- debian/control  2010-03-27 14:41:02 +
+++ debian/control  2011-07-20 19:47:36 +
@@ -3,13 +3,13 @@
 Priority: optional
 Maintainer: Debian Python Modules Team 
python-modules-team@lists.alioth.debian.org
 Uploaders: Robert S. Edmonds edmo...@debian.org
-Build-Depends: debhelper (= 5.0.38), autoconf, python-dev (= 2.4.3-11),
- apache2-threaded-dev (= 2.2.3-1), dpatch, python-central (= 0.5.6)
-XS-Python-Version: current
+Build-Depends: debhelper (= 5.0.38), autoconf, python-dev (= 2.6.6-3~),
+ apache2-threaded-dev (= 2.2.3-1), dpatch,
 Vcs-Svn: 
svn://svn.debian.org/python-modules/packages/libapache2-mod-python/trunk/
 Vcs-Browser: 
http://svn.debian.org/viewsvn/python-modules/packages/libapache2-mod-python/trunk/
 Homepage: http://www.modpython.org/
-Standards-Version: 3.8.4
+Standards-Version: 3.9.2
+X-Python-Version: = 2.7
  
 Package: libapache2-mod-python
 Architecture: any
@@ -19,7 +19,6 @@
 Replaces: libapache2-mod-python2.4 ( 3.2.8-3), libapache2-mod-python2.3 ( 
3.2.8-3)
 Conflicts: libapache2-mod-python2.4, libapache2-mod-python2.3, 
libapache2-mod-python2.2,
  libapache-mod-python, libapache-mod-python2.1, libapache-mod-python2.2, 
libapache-mod-python2.3
-XB-Python-Version: ${python:Versions}
 Description: Python-embedding module for Apache 2
  The mod_python module supports web applications written in Python.
  Because the parser is embedded in the server as an Apache module, it

=== modified file 'debian/rules'
--- debian/rules2010-03-27 14:41:02 +
+++ debian/rules2011-07-20 19:47:10 +
@@ -8,7 +8,7 @@
 
 include /usr/share/dpatch/dpatch.make
 
-PYVER=$(shell pyversions -rv)
+PYVER=$(shell pyversions -r)
 
 configure: configure-stamp
 configure-stamp:
@@ -57,7 +57,7 @@
-env PYTHON_BIN=/usr/bin/python \
./configure --with-apxs=/usr/bin/apxs2 --prefix=/usr \
--mandir=\$${prefix}/share/man --infodir=\$${prefix}/share/info 
\
-   --with-python-version=$(PYVER)
+   --with-python=$(PYVER)
$(MAKE) clean  DEB_DEFINES=-DLONG_LONG=PY_LONG_LONG $(MAKE)
$(MAKE) install DESTDIR=$(CURDIR)/debian/libapache2-mod-python
cp debian/python.load 
debian/libapache2-mod-python/etc/apache2/mods-available/
@@ -83,7 +83,7 @@
 binary-arch: build install
dh_testdir -a
dh_testroot -a
-   dh_pycentral -plibapache2-mod-python
+   dh_python2 -plibapache2-mod-python
dh_installdocs -a
dh_installexamples -a
dh_installmenu -a

[Python-modules-team] bug 625785 (virtualenv -p python3 should work, but doesn't)

[Barry Warsaw]

Hi folks,

I spent about a day and a half tracking down a problem with virtualenv.  As of
virtualenv 1.6 (which is in wheezy), it *should* be possible to use python3 as
a -p target.  This fails because the way virtualenv re-invokes itself does not
play nicely with our symlink farm.

All the gory details are here:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=625785

I haven't thought of a good way to solve this problem yet, so I'm hoping
someone here will have some thoughts on that.  I'm highly motivated to fix
this because I'm beginning to research Python 3 compatibility across Debian
and Ubuntu packages (more on that soon).

I also have patches to upgrade to virtualenv 1.6.1, which is the latest
upstream, and which now supports pypy 1.5.  Some of the debian/patches need
updating, but I'd like to solve bug 625785 first.

Cheers,
-Barry


signature.asc
Description: PGP signature
___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#625784: (no subject)

[Barry Warsaw]

Actually, try this patch.  (I'm having some difficulty committing this to svn.)
Index: patches/remove_syspath0_on_reinvoke.patch
===
--- patches/remove_syspath0_on_reinvoke.patch	(revision 0)
+++ patches/remove_syspath0_on_reinvoke.patch	(revision 0)
@@ -0,0 +1,24 @@
+Description: When reinvoked, sys.path[0] will point into /usr/share/pyshared
+ on Debian, which will cause the following import to pick up the wrong version
+ (i.e. the 2.7 version when -p python3 is used).  We don't need sys.path[0], so
+ just remove it permanently. 
+Author: Barry Warsaw ba...@python.org
+Bug-Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=625784
+Forwarded: not-needed
+--- a/virtualenv.py
 b/virtualenv.py
+@@ -469,6 +469,14 @@
+ project_name = 'distribute'
+ bootstrap_script = DISTRIBUTE_SETUP_PY
+ try:
++# When reinvoked, sys.path[0] will point into /usr/share/pyshared
++# on Debian, which will cause the following import to pick up the
++# wrong version (i.e. the 2.7 version when -p python3 is used).
++# We don't need sys.path[0], so just remove it permanently.  See
++# Debian bug 625785.
++if (os.environ.get('VIRTUALENV_INTERPRETER_RUNNING', '') == 'true'
++and sys.path[0] == '/usr/share/pyshared'):
++del sys.path[0]
+ # check if the global Python has distribute installed or plain
+ # setuptools
+ import pkg_resources
Index: patches/series
===
--- patches/series	(revision 16912)
+++ patches/series	(working copy)
@@ -1,2 +1,3 @@
 look_for_external_files.patch
 add_distribute.patch
+remove_syspath0_on_reinvoke.patch
Index: changelog
===
--- changelog	(revision 16912)
+++ changelog	(working copy)
@@ -1,3 +1,13 @@
+python-virtualenv (1.6-2) unstable; urgency=low
+
+  * debian/patches/remove_syspath0_on_reinvoke.patch
+When virtualenv.py is re-invoked, remove sys.path[0], since it points
+to /usr/share/pyshared, which causes the wrong version of
+pkg_resources to be imported.  This fixes -p python3 on Debian.
+Closes: 625784
+
+ -- Barry Warsaw ba...@python.org  Fri, 06 May 2011 15:54:09 -0400
+
 python-virtualenv (1.6-1) unstable; urgency=low
 
   * New upstream version. Closes: #617941


signature.asc
Description: PGP signature
___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#625784: python-virtualenv: 'virtualenv -p python3 xx' should work but doesn't

[Barry Warsaw]

Package: python-virtualenv
Version: 1.4.9-3ubuntu1
Severity: important


On Wheezy, which has virtualenv 1.6, the following should work:

$ virtualenv -p python3 /tmp/xx

but it fails with this traceback:

-snip snip-
Traceback (most recent call last):
  File /usr/lib/python2.6/dist-packages/virtualenv.py, line 1892, in module
main()
  File /usr/lib/python2.6/dist-packages/virtualenv.py, line 753, in main
prompt=options.prompt)
  File /usr/lib/python2.6/dist-packages/virtualenv.py, line 851, in 
create_environment
install_distribute(py_executable, unzip=unzip_setuptools)
  File /usr/lib/python2.6/dist-packages/virtualenv.py, line 575, in 
install_distribute
_install_req(py_executable, unzip, distribute=True)
  File /usr/lib/python2.6/dist-packages/virtualenv.py, line 474, in 
_install_req
import pkg_resources
  File /usr/share/pyshared/pkg_resources.py, line 45
def _bypass_ensure_directory(name, mode=0777):
   ^
SyntaxError: invalid token
-snip snip-

I've analyzed why this happens, but I haven't figured out a good fix for it
yet.  Here's my analysis.

First, virtualenv supports Python 3 as of 1.6 (and PyPy 1.5 as of 1.6.1, but
that's for a different bug report).  This is true even without specifically
building python-virtualenv for Python 3.  In other words, in a pristine
environment, you build Python 2.7 from source --prefix=/tmp/py27 and then use
'/tmp/py27/bin/python setup.py install' from the upstream virtualenv 1.6.1
tarball, then run '/tmp/py27/bin/virtualenv -p python3 /tmp/xx' it works just
fine.

Why does it fail in Debian then?  I'm glad you asked!

Notice that the traceback is actually coming from
/usr/share/pyshared/pkg_resources.py, and indeed the token 0777 is not legal
in Python 3.2.  This traceback will happen even if you've installed the
python3-pkg-resource package.  The traceback happens because virtualenv is
picking up the pkg_resources modules from Python 2 and *not* from Python3.

virtualenv works by re-invoking the Python interpreter you gave to the -p
option in a subprocess.  The arguments to that subprocess are the absolute
path back to the virtualenv.py file and the target directory you invoked on
the command line.  It also sets an environment variable so that it knows it's
running recursively.  So, in our test case, this is what the subprocess runs:

$ VIRTUALENV_INTERPRETER_RUNNING=true python3 
/usr/lib/python2.7/dist-packages/virtualenv.py

That *should* be perfectly fine because virtualenv.py is Python3 compatible.
Try it yourself and you'll see that that fails with the above traceback.

The reason is because of Debian's symlink farm.  When virtualenv.py tries to
import pkg_resources, it picks up the one from /usr/share/pyshared instead of
the one from /usr/lib/python3/dist-packages/pkg_resources.py as you would
expect.  Why is that?  Well, it's because
/usr/lib/python2.7/dist-packages/virtualenv.py is a symlink to
/usr/share/pyshared/virtualenv.py and this tricks Python's default sys.path
setup.

When Python is handed a script in argv[1], it puts that directory at the front
of sys.path, but before it does so, it chases the symlink of argv[1].  So,
Python 3 starts up, sees /usr/lib/python2.7/dist-packages/virtualenv.py in
argv[1], chases that to /usr/share/pyshared/virtualenv.py, and sticks
/usr/share/pyshared at the front of sys.path.  Our python-pkg-resources
package happens to drop a pkg_resources.py file in that directory, but that
file is only appropriate for Python 2.  So when Python 3 tries to import
pkg_resources, it gets the one from /usr/share/pyshared and boom!

Why doesn't the same thing happen in a from-source build?  Well, it's because
in a from-source build, pkg_resources doesn't live in site-packages, it lives
in site-packages/distribute-0.6.16-py2.7.egg so when Python 3 runs
.../python2.7/site-packages/virtualenv.py there is no pkg_resources.py file
right next to it, even though .../python2.7/site-packages is the first thing
on sys.path.

I don't know what the proper fix for this is though.  I'll bring it up on
debian-python and see if anybody has any ideas.


-- System Information:
Debian Release: squeeze/sid
  APT prefers natty-updates
  APT policy: (500, 'natty-updates'), (500, 'natty-security'), (500, 'natty')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.38-8-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

Versions of packages python-virtualenv depends on:
ii  python   2.7.1-0ubuntu5  interactive high-level object-orie
ii  python-pkg-resources 0.6.15-1ubuntu1 Package Discovery and Resource Acc
ii  python-setuptools0.6.15-1ubuntu1 Python Distutils Enhancements (set
ii  python-support   1.0.10ubuntu3   automated rebuilding support for P

Versions of packages python-virtualenv recommends:
ii  python-pip0.8.2-0ubuntu1 alternative Python