from:"Barry"

=== modified file 'debian/changelog'
--- debian/changelog	2012-12-10 19:10:32 +
+++ debian/changelog	2012-12-20 13:54:33 +
@@ -1,3 +1,9 @@
+python2.7 (2.7.3-13) experimental; urgency=low
+
+  * Expose multiarch triplet as sys._multiarch.  Closes: #695958
+
+ -- Barry Warsaw ba...@python.org  Thu, 20 Dec 2012 08:53:42 -0500
+
 python2.7 (2.7.3-12) experimental; urgency=low
 
   * Fix typo in pkgconfig file. Closes: #695671, LP: #1088988.

=== modified file 'debian/patches/series.in'
--- debian/patches/series.in	2012-12-10 16:06:41 +
+++ debian/patches/series.in	2012-12-20 14:29:49 +
@@ -66,3 +66,4 @@
 lib2to3-no-pickled-grammar.diff
 add-python-config-sh.diff
 ssl.match_hostname.diff
+sys-multiarch.diff

=== added file 'debian/patches/sys-multiarch.diff'
--- debian/patches/sys-multiarch.diff	1970-01-01 00:00:00 +
+++ debian/patches/sys-multiarch.diff	2012-12-20 13:53:34 +
@@ -0,0 +1,25 @@
+--- a/Makefile.pre.in
 b/Makefile.pre.in
+@@ -1304,6 +1304,11 @@
+ 
+ Python/thread.o: @THREADHEADERS@
+ 
++Python/sysmodule.o: $(srcdir)/Python/sysmodule.c Makefile
++	$(CC) -c $(PY_CORE_CFLAGS) \
++		-DMULTIARCH='$(MULTIARCH)' \
++		-o $@ $(srcdir)/Python/sysmodule.c
++
+ # Declare targets that aren't real files
+ .PHONY: all build_all sharedmods oldsharedmods test quicktest memtest
+ .PHONY: install altinstall oldsharedinstall bininstall altbininstall
+--- a/Python/sysmodule.c
 b/Python/sysmodule.c
+@@ -1435,6 +1435,8 @@
+ PyFloat_GetInfo());
+ SET_SYS_FROM_STRING(long_info,
+ PyLong_GetInfo());
++SET_SYS_FROM_STRING(_multiarch,
++PyString_FromString(MULTIARCH));
+ #ifdef Py_USING_UNICODE
+ SET_SYS_FROM_STRING(maxunicode,
+ PyInt_FromLong(PyUnicode_GetMax()));

Bug#695959: (no subject)

After discussion on Bug #695958 here is an updated patch.  This exposes the
triplet on sys.implementation._multiarch
=== modified file 'debian/changelog'
--- debian/changelog	2012-12-04 04:36:42 +
+++ debian/changelog	2012-12-20 15:04:24 +
@@ -1,3 +1,10 @@
+python3.3 (3.3.0-7) experimental; urgency=low
+
+  * debian/patches/sys-implementation.diff: Expose multiarch triplet value
+as sys.implementation._multiarch.  Closes: #695959
+
+ -- Barry Warsaw ba...@python.org  Fri, 14 Dec 2012 15:50:45 -0500
+
 python3.3 (3.3.0-6) experimental; urgency=low
 
   * Don't use xattrs on kfreebsd and the Hurd.

=== modified file 'debian/patches/series.in'
--- debian/patches/series.in	2012-12-04 04:36:42 +
+++ debian/patches/series.in	2012-12-14 20:52:45 +
@@ -54,3 +54,4 @@
 ext-no-libpython-link.diff
 add-python-config-sh.diff
 kfreebsd-xattrs.diff
+sys-implementation.diff

=== added file 'debian/patches/sys-implementation.diff'
--- debian/patches/sys-implementation.diff	1970-01-01 00:00:00 +
+++ debian/patches/sys-implementation.diff	2012-12-20 13:00:31 +
@@ -0,0 +1,28 @@
+--- a/Makefile.pre.in
 b/Makefile.pre.in
+@@ -647,6 +647,7 @@
+ Python/sysmodule.o: $(srcdir)/Python/sysmodule.c Makefile
+ 	$(CC) -c $(PY_CORE_CFLAGS) \
+ 		-DABIFLAGS='$(ABIFLAGS)' \
++		-DMULTIARCH='$(MULTIARCH)' \
+ 		-o $@ $(srcdir)/Python/sysmodule.c
+ 
+ $(IO_OBJS): $(IO_H)
+--- a/Python/sysmodule.c
 b/Python/sysmodule.c
+@@ -1534,6 +1534,15 @@
+ if (res  0)
+ goto error;
+ 
++/* For Debian multiarch support. */
++value = PyUnicode_FromString(MULTIARCH);
++if (value == NULL)
++goto error;
++res = PyDict_SetItemString(impl_info, _multiarch, value);
++Py_DECREF(value);
++if (res  0)
++goto error;
++
+ /* dict ready */
+ 
+ ns = _PyNamespace_New(impl_info);

Bug#695958: python2.7: Expose multiarch triplet in sys module

On Dec 19, 2012, at 11:57 PM, Matthias Klose wrote:

hard-coding gcc is wrong. you should use CC and have this code at a position
where it's clear which CC to use.

if this patch is debian local, you can drop the dpkg-architecture check.

This is actually much simpler than I first though.  We already have a patch to
calculate `gcc -print-multiarch` in configure.ac and it's already stashed in
the MULTIARCH autoconf variable.

So really, all my patch needs to do is to expose that in the sys module.

_architecture is a bad name. just name it _multiarch, or obfuscate it even
more (a name longer than single_version_externally_managed would be
preferred).

sys.implementation._multiarch is fine.

Make sure that the tuple ends up in _sysconfigdata.py with a
sensible name, e.g. HOST_MULTIARCH. The latter one can be overwritten for
cross builds (once the 3.3 cross build changes are backported), and should be
the preferred way to access this information.

It's already there :)

$ python3.3 -c import _sysconfigdata; 
print(_sysconfigdata.build_time_vars['MULTIARCH'])
x86_64-linux-gnu
$ python2.7 -c import _sysconfigdata; 
print(_sysconfigdata.build_time_vars['MULTIARCH'])
x86_64-linux-gnu

Updated patch attached.
=== modified file 'debian/changelog'
--- debian/changelog	2012-12-10 19:10:32 +
+++ debian/changelog	2012-12-20 15:10:49 +
@@ -1,3 +1,10 @@
+python2.7 (2.7.3-13) experimental; urgency=low
+
+  * debian/patches/sys-multiarch.diff: Expose multiarch triplet as
+sys._multiarch.  Closes: #695958
+
+ -- Barry Warsaw ba...@python.org  Thu, 20 Dec 2012 08:53:42 -0500
+
 python2.7 (2.7.3-12) experimental; urgency=low
 
   * Fix typo in pkgconfig file. Closes: #695671, LP: #1088988.

=== modified file 'debian/patches/series.in'
--- debian/patches/series.in	2012-12-10 16:06:41 +
+++ debian/patches/series.in	2012-12-20 15:10:49 +
@@ -66,3 +66,4 @@
 lib2to3-no-pickled-grammar.diff
 add-python-config-sh.diff
 ssl.match_hostname.diff
+sys-multiarch.diff

=== added file 'debian/patches/sys-multiarch.diff'
--- debian/patches/sys-multiarch.diff	1970-01-01 00:00:00 +
+++ debian/patches/sys-multiarch.diff	2012-12-20 15:10:49 +
@@ -0,0 +1,25 @@
+--- a/Makefile.pre.in
 b/Makefile.pre.in
+@@ -1304,6 +1304,11 @@
+ 
+ Python/thread.o: @THREADHEADERS@
+ 
++Python/sysmodule.o: $(srcdir)/Python/sysmodule.c Makefile
++	$(CC) -c $(PY_CORE_CFLAGS) \
++		-DMULTIARCH='$(MULTIARCH)' \
++		-o $@ $(srcdir)/Python/sysmodule.c
++
+ # Declare targets that aren't real files
+ .PHONY: all build_all sharedmods oldsharedmods test quicktest memtest
+ .PHONY: install altinstall oldsharedinstall bininstall altbininstall
+--- a/Python/sysmodule.c
 b/Python/sysmodule.c
+@@ -1435,6 +1435,8 @@
+ PyFloat_GetInfo());
+ SET_SYS_FROM_STRING(long_info,
+ PyLong_GetInfo());
++SET_SYS_FROM_STRING(_multiarch,
++PyString_FromString(MULTIARCH));
+ #ifdef Py_USING_UNICODE
+ SET_SYS_FROM_STRING(maxunicode,
+ PyInt_FromLong(PyUnicode_GetMax()));

=== modified file 'debian/changelog'
--- debian/changelog	2012-12-10 19:10:32 +
+++ debian/changelog	2012-12-20 15:10:49 +
@@ -1,3 +1,10 @@
+python2.7 (2.7.3-13) experimental; urgency=low
+
+  * debian/patches/sys-multiarch.diff: Expose multiarch triplet as
+sys._multiarch.  Closes: #695958
+
+ -- Barry Warsaw ba...@python.org  Thu, 20 Dec 2012 08:53:42 -0500
+
 python2.7 (2.7.3-12) experimental; urgency=low
 
   * Fix typo in pkgconfig file. Closes: #695671, LP: #1088988.

=== modified file 'debian/patches/series.in'
--- debian/patches/series.in	2012-12-10 16:06:41 +
+++ debian/patches/series.in	2012-12-20 15:10:49 +
@@ -66,3 +66,4 @@
 lib2to3-no-pickled-grammar.diff
 add-python-config-sh.diff
 ssl.match_hostname.diff
+sys-multiarch.diff

=== added file 'debian/patches/sys-multiarch.diff'
--- debian/patches/sys-multiarch.diff	1970-01-01 00:00:00 +
+++ debian/patches/sys-multiarch.diff	2012-12-20 15:10:49 +
@@ -0,0 +1,25 @@
+--- a/Makefile.pre.in
 b/Makefile.pre.in
+@@ -1304,6 +1304,11 @@
+ 
+ Python/thread.o: @THREADHEADERS@
+ 
++Python/sysmodule.o: $(srcdir)/Python/sysmodule.c Makefile
++	$(CC) -c $(PY_CORE_CFLAGS) \
++		-DMULTIARCH='$(MULTIARCH)' \
++		-o $@ $(srcdir)/Python/sysmodule.c
++
+ # Declare targets that aren't real files
+ .PHONY: all build_all sharedmods oldsharedmods test quicktest memtest
+ .PHONY: install altinstall oldsharedinstall bininstall altbininstall
+--- a/Python/sysmodule.c
 b/Python/sysmodule.c
+@@ -1435,6 +1435,8 @@
+ PyFloat_GetInfo());
+ SET_SYS_FROM_STRING(long_info,
+ PyLong_GetInfo());
++SET_SYS_FROM_STRING(_multiarch,
++PyString_FromString(MULTIARCH));
+ #ifdef Py_USING_UNICODE
+ SET_SYS_FROM_STRING(maxunicode,
+ PyInt_FromLong(PyUnicode_GetMax()));



signature.asc
Description: PGP signature

Bug#695959: (no subject)

Sorry, one more patch.  This is the last one, I promise.
=== modified file 'debian/changelog'
--- debian/changelog	2012-12-04 04:36:42 +
+++ debian/changelog	2012-12-20 15:13:05 +
@@ -1,3 +1,10 @@
+python3.3 (3.3.0-7) experimental; urgency=low
+
+  * debian/patches/sys-multiarch.diff: Expose multiarch triplet value
+as sys.implementation._multiarch.  Closes: #695959
+
+ -- Barry Warsaw ba...@python.org  Fri, 14 Dec 2012 15:50:45 -0500
+
 python3.3 (3.3.0-6) experimental; urgency=low
 
   * Don't use xattrs on kfreebsd and the Hurd.

=== modified file 'debian/patches/series.in'
--- debian/patches/series.in	2012-12-04 04:36:42 +
+++ debian/patches/series.in	2012-12-20 15:12:47 +
@@ -54,3 +54,4 @@
 ext-no-libpython-link.diff
 add-python-config-sh.diff
 kfreebsd-xattrs.diff
+sys-multiarch.diff

=== added file 'debian/patches/sys-multiarch.diff'
--- debian/patches/sys-multiarch.diff	1970-01-01 00:00:00 +
+++ debian/patches/sys-multiarch.diff	2012-12-20 13:00:31 +
@@ -0,0 +1,28 @@
+--- a/Makefile.pre.in
 b/Makefile.pre.in
+@@ -647,6 +647,7 @@
+ Python/sysmodule.o: $(srcdir)/Python/sysmodule.c Makefile
+ 	$(CC) -c $(PY_CORE_CFLAGS) \
+ 		-DABIFLAGS='$(ABIFLAGS)' \
++		-DMULTIARCH='$(MULTIARCH)' \
+ 		-o $@ $(srcdir)/Python/sysmodule.c
+ 
+ $(IO_OBJS): $(IO_H)
+--- a/Python/sysmodule.c
 b/Python/sysmodule.c
+@@ -1534,6 +1534,15 @@
+ if (res  0)
+ goto error;
+ 
++/* For Debian multiarch support. */
++value = PyUnicode_FromString(MULTIARCH);
++if (value == NULL)
++goto error;
++res = PyDict_SetItemString(impl_info, _multiarch, value);
++Py_DECREF(value);
++if (res  0)
++goto error;
++
+ /* dict ready */
+ 
+ ns = _PyNamespace_New(impl_info);

Bug#695707: (no subject)

Alioth svn updated with latest patch based on comments in bug #695958.  Once
that gets uploaded, then svn can get sponsored to fix the problem.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#679967: (no subject)

With 6.1.0 I can not reproduce this.  I think Andreas fixed a lot of problems
in this area, so I'll mark this as closed by the new version.  Feel free of
course to re-open if it happens again.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#208303: (no subject)

Forwarded upstream:

https://bugs.launchpad.net/debian/+bug/1092794


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#695958: python2.7: Expose multiarch triplet in sys module

2012-12-19 Thread Barry Warsaw

On Dec 19, 2012, at 12:50 PM, Jakub Wilk wrote:

* Barry Warsaw ba...@python.org, 2012-12-14, 16:29:
++dnl Debian multiarch support in sys.implementation._architecture
++dnl Try `dpkg-architecture -qDEB_BUILD_MULTIARCH` first, then
++dnl `gcc --print-multiarch`.
++AC_SUBST(MULTIARCH_BUILD)
++AC_CHECK_PROG(HAS_DPKG_ARCHITECTURE, dpkg-architecture, found, not-found)
++if test $HAS_DPKG_ARCHITECTURE = found
++then
++MULTIARCH_BUILD=dpkg-architecture -qDEB_BUILD_MULTIARCH
++else
++AC_CHECK_PROG(HAS_GCC_FOR_ARCH, gcc, found, not-found)
++if test $HAS_GCC_FOR_ARCH = found
++then
++MULTIARCH_BUILD=gcc --print-multiarch
++else
++MULTIARCH_BUILD=
++fi
++fi

s/DEB_BUILD_MULTIARCH/DEB_HOST_MULTIARCH/ presumably?

Yes, I think you're right.  Thanks.

(Does it make sense to expose the other dpkg-architecture stuff, or should we
just keep it simple?)


signature.asc
Description: PGP signature

Bug#695707: Fixing python-virtualenv for Python 2.7

2012-12-17 Thread Barry Warsaw

If you apply the multarchi27.diff patch in bug #695958, then this patch to
virtualenv will do the trick.

Ignore the earlier two python-virtualenv patches.

=== modified file 'debian/changelog'
--- debian/changelog	2012-11-30 15:06:23 +
+++ debian/changelog	2012-12-12 19:11:43 +
@@ -1,3 +1,10 @@
+python-virtualenv (1.8.4-2) experimental; urgency=low
+
+  * debian/patches/multiarch.patch: Use system multiarch path if available.
+Closes: #695707
+
+ -- Barry Warsaw ba...@python.org  Wed, 12 Dec 2012 14:10:49 -0500
+
 python-virtualenv (1.8.4-1) experimental; urgency=low
 
   * Team upload.

=== added file 'debian/patches/multiarch.patch'
--- debian/patches/multiarch.patch	1970-01-01 00:00:00 +
+++ debian/patches/multiarch.patch	2012-12-17 19:26:03 +
@@ -0,0 +1,24 @@
+Description: Use system multiarch path if available.
+Author: Barry Warsaw ba...@python.org
+Bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=695707
+Forwarded: no
+
+--- a/virtualenv_embedded/site.py
 b/virtualenv_embedded/site.py
+@@ -584,9 +584,13 @@
+ paths.insert(0, lib64_path)
+ else:
+ paths.append(lib64_path)
+-# This is hardcoded in the Python executable, but relative to sys.prefix:
+-plat_path = os.path.join(sys.real_prefix, 'lib', 'python'+sys.version[:3],
+- 'plat-%s' % sys.platform)
++# This is hardcoded in the Python executable, but relative to
++# sys.prefix.  In Python 3.3+ the multiarch triplet lives in (as per
++# PEP 421) sys.implementation, but in Python 2.7 it lives in sys.
++multiarch = getattr(sys, 'implementation', sys)._architecture
++plat_path = os.path.join(sys.real_prefix, 'lib',
++ 'python'+sys.version[:3],
++ 'plat-%s' % multiarch)
+ if os.path.exists(plat_path):
+ paths.append(plat_path)
+ # This is hardcoded in the Python executable, but

=== modified file 'debian/patches/series'
--- debian/patches/series	2012-11-30 15:06:23 +
+++ debian/patches/series	2012-12-12 19:10:23 +
@@ -2,3 +2,4 @@
 use_distribute.patch
 system-python.patch
 entry-points.patch
+multiarch.patch

Bug#695958: python2.7: Expose multiarch triplet in sys module

2012-12-14 Thread Barry Warsaw

Package: python2.7
Version: 2.7.3~rc2-2.1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear Maintainer,

We have several cases where the multiarch triplet is needed for the
proper building or functioning of other Python modules or
applications.  A recent example is virtualenv.  In the debian-python
mailing list, several solutions for the virtualenv problem have been
discussed, but all of them are unsatisfying.

What we really need is an officially approved, common way of getting
the triplet, that doesn't require shelling out or globbing the file
system.  When Python is built, it already knows (or can easily find
out) what the triplet should be, so it's best if we expose this in the
sys module.

Attached is a patch similar to one discussed on debian-python.  It
exposes the triplet as `sys._architecture`.  A similar patch will be
made available for Python 3.3, except that there, it will be avialable
under `sys.implementation._architecture` as per PEP 421.  Bilingual
Python code can use:

 import sys
 getattr(sys, 'implementation', sys)._architecture

Cheers.


- -- 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 python2.7 depends on:
ii  libbz2-1.0 1.0.6-4
ii  libc6  2.13-37
ii  libdb5.1   5.1.29-5
ii  libexpat1  2.1.0-1
ii  libgcc11:4.7.2-4
ii  libncursesw5   5.9-10
ii  libreadline6   6.2-8
ii  libsqlite3-0   3.7.13-1
ii  libtinfo5  5.9-10
ii  mime-support   3.52-1
ii  python2.7-minimal  2.7.3~rc2-2.1

python2.7 recommends no packages.

Versions of packages python2.7 suggests:
ii  binutils   2.22-7.1
pn  python2.7-doc  none

- -- no debconf information

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

iQIbBAEBCAAGBQJQy5pQAAoJEBJutWOnSwa/e1QP91RxE/xWAUKQvSM08BEZsmW6
J7NEgCOz5GNIM2nG2VxTL2L2s3dxNNODhMi9r35RrmgSeTkkiUmMiqpL5hKPiVMs
5bjIA/GHYfdZp3wt52qBA2KckvW9D0257QoMs+d5j0lHs/syijTPLGvg9qAJx70L
4SsjZSCnJ4aKpYvu8je8RKc2lzmsLBuY6NuIoIRbee0KhZoXwXwb0y0JNpUj7r2T
QlCiM9dh8OS2vMtiRmL27/jT1HWLnoT3tkBzkP/eaYP+wyhwbIsQ8q9Ltk5PtzMV
gX/N7sy8QnetNopILxAhmK+h0O9OoH5Is4WrF8USsAJeb8TWLmxOjTTlDmHGyIde
xOqj7hlhzc+uNzR/jB09j7Uszj7J0i0hunJadGCmCTk/OunY5Y+IKHBA78+JSNVI
hF8j81p6iTg1BNzrcrKAwzbkXFWD/bUgK85xBP1wdtm6srIKVyBfSw5eqiuAVfgw
SwLyhiqZPz+UeFXaSKgOGAYLW+do5qZdaQ64CbXTAjm5P/hZR7+xwfA0cnla9RT5
ZclZnHojln9uw/9i1mTMZ+278hnIbTzfzxRkmaNUmKN7VV0gDry9ltlUJtHsGb3C
Kn/jYSVsnSqCV06qm2x4Gei5sPqlVN/TpuvEssf5ZnK40mSVMKvTDnit9Gvmh/yU
viPWNZdWPBrqaSJ2gAc=
=2fr2
-END PGP SIGNATURE-
=== modified file 'debian/changelog'
--- debian/changelog	2012-12-10 19:10:32 +
+++ debian/changelog	2012-12-14 20:24:32 +
@@ -1,3 +1,10 @@
+python2.7 (2.7.3-13) experimental; urgency=low
+
+  * debian/patches/sys-implementation.diff: Expose multiarch triplet value
+as sys._architecture.
+
+ -- Barry Warsaw ba...@python.org  Fri, 14 Dec 2012 15:23:02 -0500
+
 python2.7 (2.7.3-12) experimental; urgency=low
 
   * Fix typo in pkgconfig file. Closes: #695671, LP: #1088988.

=== modified file 'debian/patches/series.in'
--- debian/patches/series.in	2012-12-10 16:06:41 +
+++ debian/patches/series.in	2012-12-14 20:24:32 +
@@ -66,3 +66,4 @@
 lib2to3-no-pickled-grammar.diff
 add-python-config-sh.diff
 ssl.match_hostname.diff
+sys-implementation.diff

=== added file 'debian/patches/sys-implementation.diff'
--- debian/patches/sys-implementation.diff	1970-01-01 00:00:00 +
+++ debian/patches/sys-implementation.diff	2012-12-14 20:24:32 +
@@ -0,0 +1,60 @@
+--- a/configure.ac
 b/configure.ac
+@@ -24,6 +24,24 @@
+ prefix=`echo $prefix | sed -e 's/\/$//g'`
+ fi
+ 
++dnl Debian multiarch support in sys.implementation._architecture
++dnl Try `dpkg-architecture -qDEB_BUILD_MULTIARCH` first, then
++dnl `gcc --print-multiarch`.
++AC_SUBST(MULTIARCH_BUILD)
++AC_CHECK_PROG(HAS_DPKG_ARCHITECTURE, dpkg-architecture, found, not-found)
++if test $HAS_DPKG_ARCHITECTURE = found
++then
++MULTIARCH_BUILD=dpkg-architecture -qDEB_BUILD_MULTIARCH
++else
++AC_CHECK_PROG(HAS_GCC_FOR_ARCH, gcc, found, not-found)
++if test $HAS_GCC_FOR_ARCH = found
++then
++MULTIARCH_BUILD=gcc --print-multiarch
++else
++MULTIARCH_BUILD=
++fi
++fi
++
+ dnl This is for stuff that absolutely must end up in pyconfig.h.
+ dnl Please use pyport.h instead, if possible.
+ AH_TOP([
+--- a/Makefile.pre.in
 b/Makefile.pre.in
+@@ -40,6 +40,7 @@
+ HGVERSION=	@HGVERSION@
+ HGTAG=		@HGTAG@
+ HGBRANCH=	@HGBRANCH@
++MULTIARCH_BUILD=	@MULTIARCH_BUILD@
+ 
+ GNULD=  @GNULD@
+ 
+@@ -1304,6 +1305,11 @@
+ 
+ Python/thread.o: @THREADHEADERS@
+ 
++Python/sysmodule.o: $(srcdir)/Python/sysmodule.c Makefile
++	$(CC) -c $(PY_CORE_CFLAGS) \
++		-DMULTIARCH_BUILD=\`LC_ALL=C $(MULTIARCH_BUILD

Bug#695959: python3.3: Expose multiarch triplet in sys module

2012-12-14 Thread Barry Warsaw

Package: python3.3
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear Maintainer,

We have several cases where the multiarch triplet is needed for the
proper building or functioning of other Python modules or
applications.  A recent example is virtualenv.  In the debian-python
mailing list, several solutions for the virtualenv problem have been
discussed, but all of them are unsatisfying.

What we really need is an officially approved, common way of getting
the triplet, that doesn't require shelling out or globbing the file
system.  When Python is built, it already knows (or can easily find
out) what the triplet should be, so it's best if we expose this in the
sys module.

Attached is a patch similar to one discussed on debian-python.  It
exposes the triplet as sys.implementation_architecture.  A similar
patch has been made available for Python 2.7, except that there, it
will be avialable under sys._architecture.  

Bilingual Python code can use:

 import sys
 getattr(sys, 'implementation', sys)._architecture  

Cheers.


- -- 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

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

iQIcBAEBCAAGBQJQy56RAAoJEBJutWOnSwa/W3wP/ili/1kfbJu7sZvy2LjrgYPJ
TXepiU7cp1Ezj5ZQFNMZf7vT9vguamuQfXSXuEaMbzuB22oKaGfdBmVjO9uWppxY
3SJ6Qm8WKM2xcRGmGHVKgwBD7lH1AnUIVSWwz0UMqw7Q6gc2SIYI8ESEYfCvLMRV
WVscW9iUMxrzBqHT099PWe7DdCWPhckEnNL76L+uNXkco3HgwasYo+mO/oHCoAVB
h67VbWdc2FBo3sbtcf8UQVmAfXeWL5ek1qw7QL2MCAxFR+0rdqj3zRa80+ZhP3Tu
zsJqzTietpaS8mnM5fSzsW6yWGutsuBk958cxb4jlKN88U6rvQvM0I+duYzVmSIU
gP4iG/F4I5yEN1J41Jpm6xYBOjmmGyHRoDcsnRl3r0bjNnY1JmgymOjnQvTqTYso
0dUR+Oddvd/2PoMr1xWHHstCI5QszbTutXVWMf/cSZPkcbyWuJOTR8p0UU1WzOsO
TDmp2OoT/h6/VYuK/MQbEAZMm11A704M4P4rcC2ct045ao/2zRGVJ5cbbvrTbU69
Dy6HbkqeNMBmXsU9jHdyD20jhC9c/WSF3hEKXnMsddNWu6AyM1/4dOrT6UJ1ufxT
Gw26A15YtS+ySAcSmwYwb6YcaLjSMyOFpH9x4qpWbTVWZLGqxRccHsqMcfPHOrrr
ZQpXIbw85BsTZ29UCbfP
=vxcp
-END PGP SIGNATURE-
=== modified file 'debian/changelog'
--- debian/changelog	2012-12-04 04:36:42 +
+++ debian/changelog	2012-12-14 20:52:07 +
@@ -1,3 +1,10 @@
+python3.3 (3.3.0-7) experimental; urgency=low
+
+  * debian/patches/sys-implementation.diff: Expose multiarch triplet value
+as sys._architecture.
+
+ -- Barry Warsaw ba...@python.org  Fri, 14 Dec 2012 15:50:45 -0500
+
 python3.3 (3.3.0-6) experimental; urgency=low
 
   * Don't use xattrs on kfreebsd and the Hurd.

=== modified file 'debian/patches/series.in'
--- debian/patches/series.in	2012-12-04 04:36:42 +
+++ debian/patches/series.in	2012-12-14 20:52:07 +
@@ -54,3 +54,4 @@
 ext-no-libpython-link.diff
 add-python-config-sh.diff
 kfreebsd-xattrs.diff
+sys-implementation.diff

=== added file 'debian/patches/sys-implementation.diff'
--- debian/patches/sys-implementation.diff	1970-01-01 00:00:00 +
+++ debian/patches/sys-implementation.diff	2012-12-14 20:52:07 +
@@ -0,0 +1,63 @@
+--- a/configure.ac
 b/configure.ac
+@@ -84,6 +84,24 @@
+ prefix=`echo $prefix | sed -e 's/\/$//g'`
+ fi
+ 
++dnl Debian multiarch support in sys.implementation._architecture
++dnl Try `dpkg-architecture -qDEB_BUILD_MULTIARCH` first, then
++dnl `gcc --print-multiarch`.
++AC_SUBST(MULTIARCH_BUILD)
++AC_CHECK_PROG(HAS_DPKG_ARCHITECTURE, dpkg-architecture, found, not-found)
++if test $HAS_DPKG_ARCHITECTURE = found
++then
++MULTIARCH_BUILD=dpkg-architecture -qDEB_BUILD_MULTIARCH
++else
++AC_CHECK_PROG(HAS_GCC_FOR_ARCH, gcc, found, not-found)
++if test $HAS_GCC_FOR_ARCH = found
++then
++MULTIARCH_BUILD=gcc --print-multiarch
++else
++MULTIARCH_BUILD=
++fi
++fi
++
+ dnl This is for stuff that absolutely must end up in pyconfig.h.
+ dnl Please use pyport.h instead, if possible.
+ AH_TOP([
+--- a/Makefile.pre.in
 b/Makefile.pre.in
+@@ -43,6 +43,7 @@
+ HGVERSION=	@HGVERSION@
+ HGTAG=		@HGTAG@
+ HGBRANCH=	@HGBRANCH@
++MULTIARCH_BUILD=	@MULTIARCH_BUILD@
+ 
+ GNULD=		@GNULD@
+ 
+@@ -647,6 +648,7 @@
+ Python/sysmodule.o: $(srcdir)/Python/sysmodule.c Makefile
+ 	$(CC) -c $(PY_CORE_CFLAGS) \
+ 		-DABIFLAGS='$(ABIFLAGS)' \
++		-DMULTIARCH_BUILD=\`LC_ALL=C $(MULTIARCH_BUILD)`\ \
+ 		-o $@ $(srcdir)/Python/sysmodule.c
+ 
+ $(IO_OBJS): $(IO_H)
+--- a/Python/sysmodule.c
 b/Python/sysmodule.c
+@@ -1534,6 +1534,15 @@
+ if (res  0)
+ goto error;
+ 
++/* For Debian multiarch support. */
++value = PyUnicode_FromString(MULTIARCH_BUILD);
++if (value == NULL)
++goto error;
++res = PyDict_SetItemString(impl_info, _architecture, value);
++Py_DECREF(value);
++if (res  0)
++goto error;
++
+ /* dict ready */
+ 
+ ns = _PyNamespace_New(impl_info);

Bug#695707: (no subject)

2012-12-13 Thread Barry Warsaw

On Dec 13, 2012, at 11:04 AM, Matthias Klose wrote:

Am 12.12.2012 21:06, schrieb Barry Warsaw:
 Or this one...

when creating a virtualenv, you usually know which interpreter you'll be
using for the new env, so why not use the interpreter to get the name of the
dir?

python -S -c 'import sys, os.path; print [os.path.basename(d) for d in
sys.path if os.path.basename(d).startswith(plat-)][0]'

I really don't want to promote hacks like this.  It will lead everyone to
inventing their own slightly different ways of doing it, and then we'll have
no clear recommendations, but a million opinions and hacks.

Please see the discussion on debian-python.


signature.asc
Description: PGP signature

Bug#695707: (no subject)

2012-12-12 Thread Barry Warsaw

How horrible is it to use dpkg-architecture?  It adds a dependency on
dpkg-dev, but that doesn't seem so bad to *me*. :)

Attached is a patch that uses dpkg-architecture and fixes the problem for me.
=== modified file 'debian/changelog'
--- debian/changelog	2012-11-30 15:06:23 +
+++ debian/changelog	2012-12-12 19:11:43 +
@@ -1,3 +1,10 @@
+python-virtualenv (1.8.4-2) experimental; urgency=low
+
+  * debian/patches/multiarch.patch: Use system multiarch path if available.
+Closes: #695707
+
+ -- Barry Warsaw ba...@python.org  Wed, 12 Dec 2012 14:10:49 -0500
+
 python-virtualenv (1.8.4-1) experimental; urgency=low
 
   * Team upload.

=== modified file 'debian/control'
--- debian/control	2012-04-22 17:34:40 +
+++ debian/control	2012-12-12 19:13:44 +
@@ -19,6 +19,7 @@
 Depends:
  python-pkg-resources,
  python-setuptools,
+ dpkg-dev,
  ${misc:Depends},
  ${python:Depends}
 Recommends: python-pip (= 0.7.2)

=== added file 'debian/patches/multiarch.patch'
--- debian/patches/multiarch.patch	1970-01-01 00:00:00 +
+++ debian/patches/multiarch.patch	2012-12-12 19:29:25 +
@@ -0,0 +1,33 @@
+Description: Use system multiarch path if available.
+Author: Barry Warsaw ba...@python.org
+Bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=695707
+Forwarded: no
+
+--- a/virtualenv_embedded/site.py
 b/virtualenv_embedded/site.py
+@@ -83,6 +83,16 @@
+ USER_SITE = None
+ USER_BASE = None
+ 
++# Debian multiarch support.
++# http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=695707
++# We can't use subprocess here. :/
++try:
++with os.popen('dpkg-architecture -qDEB_HOST_MULTIARCH') as fp:
++host_arch = fp.read().splitlines()[0]
++except IndexError:
++host_arch = ''
++plat_arch = 'plat-%s' % (sys.platform if not host_arch else host_arch)
++
+ _is_pypy = hasattr(sys, 'pypy_version_info')
+ _is_jython = sys.platform[:4] == 'java'
+ if _is_jython:
+@@ -570,7 +580,7 @@
+ #
+ # This is hardcoded in the Python executable, but relative to sys.prefix:
+ for path in paths[:]:
+-plat_path = os.path.join(path, 'plat-%s' % sys.platform)
++plat_path = os.path.join(path, plat_arch)
+ if os.path.exists(plat_path):
+ paths.append(plat_path)
+ elif sys.platform == 'win32':

=== modified file 'debian/patches/series'
--- debian/patches/series	2012-11-30 15:06:23 +
+++ debian/patches/series	2012-12-12 19:10:23 +
@@ -2,3 +2,4 @@
 use_distribute.patch
 system-python.patch
 entry-points.patch
+multiarch.patch

Bug#695707: (no subject)

2012-12-12 Thread Barry Warsaw

Or this one...
=== modified file 'debian/changelog'
--- debian/changelog	2012-11-30 15:06:23 +
+++ debian/changelog	2012-12-12 19:11:43 +
@@ -1,3 +1,10 @@
+python-virtualenv (1.8.4-2) experimental; urgency=low
+
+  * debian/patches/multiarch.patch: Use system multiarch path if available.
+Closes: #695707
+
+ -- Barry Warsaw ba...@python.org  Wed, 12 Dec 2012 14:10:49 -0500
+
 python-virtualenv (1.8.4-1) experimental; urgency=low
 
   * Team upload.

=== modified file 'debian/control'
--- debian/control	2012-04-22 17:34:40 +
+++ debian/control	2012-12-12 19:13:44 +
@@ -19,6 +19,7 @@
 Depends:
  python-pkg-resources,
  python-setuptools,
+ dpkg-dev,
  ${misc:Depends},
  ${python:Depends}
 Recommends: python-pip (= 0.7.2)

=== added file 'debian/patches/multiarch.patch'
--- debian/patches/multiarch.patch	1970-01-01 00:00:00 +
+++ debian/patches/multiarch.patch	2012-12-12 20:01:03 +
@@ -0,0 +1,44 @@
+Description: Use system multiarch path if available.
+Author: Barry Warsaw ba...@python.org
+Bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=695707
+Forwarded: no
+
+--- a/virtualenv_embedded/site.py
 b/virtualenv_embedded/site.py
+@@ -83,6 +83,22 @@
+ USER_SITE = None
+ USER_BASE = None
+ 
++# Debian multiarch support.
++# http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=695707
++# We can't use subprocess here. :/
++host_architectures = []
++for command in ['dpkg-architecture -qDEB_HOST_MULTIARCH',
++'gcc -print-multiarch',
++]:
++try:
++with os.popen(command) as fp:
++host_arch = fp.read().splitlines()[0]
++if host_arch not in host_architectures:
++host_architectures.append(host_arch)
++except IndexError:
++pass
++host_architectures.append('plat-%s' % sys.platform)
++
+ _is_pypy = hasattr(sys, 'pypy_version_info')
+ _is_jython = sys.platform[:4] == 'java'
+ if _is_jython:
+@@ -570,9 +586,10 @@
+ #
+ # This is hardcoded in the Python executable, but relative to sys.prefix:
+ for path in paths[:]:
+-plat_path = os.path.join(path, 'plat-%s' % sys.platform)
+-if os.path.exists(plat_path):
+-paths.append(plat_path)
++for host_arch in host_architectures:
++plat_path = os.path.join(path, host_arch)
++if os.path.exists(plat_path):
++paths.append(plat_path)
+ elif sys.platform == 'win32':
+ paths = [os.path.join(sys.real_prefix, 'Lib'), os.path.join(sys.real_prefix, 'DLLs')]
+ else:

=== modified file 'debian/patches/series'
--- debian/patches/series	2012-11-30 15:06:23 +
+++ debian/patches/series	2012-12-12 19:10:23 +
@@ -2,3 +2,4 @@
 use_distribute.patch
 system-python.patch
 entry-points.patch
+multiarch.patch

Bug#690575: python-coverage for Python 3

2012-12-10 Thread Barry Warsaw

On Dec 11, 2012, at 08:18 AM, Ben Finney wrote:

Good idea. Port 9 is the “discard” service. But why that particular
address?

The Crazy Circumstantial Conditions of the Cult of the Cargo.

 This should probably be mandatory for any distutils based package. ;)

It's a band-aid over the real problem, that of distutils expecting internet
access for build/install actions.

Well, yeah, there's that.  It's a useful feature for some development regimes
(virtualenv, buildout), if you trust PyPI of course, but I think we'll have
more luck preventing it in package builds than changing
Python/setuptools/distribute to change their behavior.


signature.asc
Description: PGP signature

Bug#690575: python-coverage for Python 3

2012-12-10 Thread Barry Warsaw

On Dec 10, 2012, at 01:46 PM, Dmitry Shachnev wrote:

It doesn't find python3 version on distribute, so calls
use_setuptools() which tries to download one from pypi.python.org.
This is a serious bug. You should add a build-dependency on
python3-setuptools, and to be sure you may also want to remove lines
38–46 from setup.py.

Also, please put this near the top of your d/rules file:

-snip snip-
# Prevent setuptools/distribute from accessing the internet.
export http_proxy = http://127.0.9.1:9
-snip snip-

This should probably be mandatory for any distutils based package. ;)



signature.asc
Description: PGP signature

Bug#694803: Wheezy beta4 installation report

2012-11-30 Thread Barry Tennison

 driver in use: ata_piix
02:00.0 Ethernet controller [0200]: D-Link System Inc DGE-528T Gigabit
Ethernet Adapter [1186:4300] (rev 10)
Subsystem: D-Link System Inc DGE-528T Gigabit Ethernet Adapter 
[1186:4300]
Kernel driver in use: r8169


Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [O]
Detect network card:[O]
Configure network:  [O]
Detect CD:  [O]
Load installer modules: [O]
Detect hard drives: [O]
Partition hard drives:  [O]
Install base system:[O]
Clock/timezone setup:   [O]
User/password setup:[O]
Install tasks:  [O]
Install boot loader:[O]
Overall install:[E ]

Comments/Problems:

Install went fine (grub installed) until first reboot (at end of
installation process)
Then had two problems which I've seen before, and I think people
should be given workarounds for them if the installer can't cope with
them.

Both problems relate to CRT display, probably about failure of auto-detect.
NB the machine's graphics device is on-motherboard and described as
'Intel® G33 x86/MMX/SSE2'

Problem 1: on booting uncorrected install, part-way through boot
process, display went blank with (display hardware-generated) box
saying:
'Out of range
' HF=30-96 KHz
' VF=47-160 Hz
'106 KHz  75Hz
which I guess you can easily interpret.
Disconcertingly, THIS HAPPENED EVEN WHEN BOOTING IN recovery MODE
(apologies for shouting, but that's very disconcerting!)

My workaround: edit grub command string by adding to linux command the
string 'video=1024x768@75' (and boot in recovery mode to avoid
entering X11).
More permanent workaround: add this string as a default linux kernel
para=meter in /etc/default/grub

Problem 2: I had installed the Debian Desktop (gnome), and even with
the 'Problem 1' workaround above, entry to X11 failed as in Problem 1.
But at least I could ctrl-alt-F1 to a text terminal.

My workaround: create (or copy across from previous install) a pretty
minimal /etc/X11/xorg.conf with a couple of stanzas like:

Section Monitor
Identifier Hansol 920D
VendorName Hansol
ModelName  920D
HorizSync   30.0 - 96.0
VertRefresh 47.0 - 160.0
Option DPMS
EndSection

Section Screen
Identifier Default Screen
MonitorHansol 920D
EndSection

With this in place, booting to gnome works fine.

Hope that helps!

Barry

Bug#693721: python2.7: modules built with distutils + --prefix=/usr not installed in sys.path

2012-11-30 Thread Barry Warsaw

On Nov 30, 2012, at 05:24 AM, Matthias Klose wrote:

So, Barry's [CCed] concern was that an upstream build without any options
would include /usr/local/lib/python2.7/site-packages, which was used by
debian policy as well. Therefore the debian system build now uses
dist-packages for /usr and /usr/local. Otoh, it's most likely that you do
want to use the system packages for everything else, e.g. when building
library bindings.

Historically[1], a from-source build of Python using the default configure,
would install Python into /usr/local/bin, with
/usr/local/lib/pythonX.Y/site-packages being where third party modules got
installed.

Debian's interpretation of the FHS allows system owners to install third party
software outside of the packaging system to install Python modules into
/usr/local/lib/pythonX.Y/site-packages, and for those to be visible to the
system Python.  Thus we have a clash, because if I install Python from source
and some third party modules (e.g. for isolation from the system Python), I
could potentially break my system Python.  Worse, it might work on Solaris and
Gentoo, but break on Debian and Ubuntu.

The solution (many years field tested by now) was the switch to dist-packages
as the place that the Debian packaging system installs modules and putting
/usr/local/lib/pythonX.Y/dist-packages on sys.path.  This eliminates potential
conflicts between system Python and a from-source install.

My suggestion for upstream Xen would be to amend its build command line to
something like this:

$(PYTHON) setup.py install --prefix=$(PREFIX) $(INSTALL_LAYOUT)

Normally $INSTALL_LAYOUT would be empty so people doing Xen builds from source
would just get whatever behavior is typical for the Python they're using.  The
Debian packager would then define INSTALL_LAYOUT='--install-layout=deb' and it
would Just Work.

Then, if Xen users wanted to install Xen from source into their system
Python[2] they would have to either provide the $INSTALL_LAYOUT value, or add
/usr/local/lib/pythonX.Y/site-packages to their sys.path manually.

Cheers,
-Barry

[1] I'm not sure how far back it goes, but at least since 1994 when I became
involved in Python, but it was true for other *nix free software long before
that.

[2] Which I personally think is a bit suspect since IMHO only Debian packages
should be used with the system Python - and why not use virtualenv or a
from-source build of Python?


signature.asc
Description: PGP signature

Bug#693721: python2.7: modules built with distutils + --prefix=/usr not installed in sys.path

2012-11-30 Thread Barry Warsaw

On Nov 30, 2012, at 10:27 AM, Ian Campbell wrote:

BTW, why is this Debian specific? Don't all these arguments about
system-python vs. custom-python apply to all distros? Or is this stuff
going to happen upstream too?

It might not, since not all distros or platforms have the same interpretation
of /usr/local as Debian does.



signature.asc
Description: PGP signature

Bug#693721: python2.7: modules built with distutils + --prefix=/usr not installed in sys.path

2012-11-30 Thread Barry Warsaw

FWIW, let's reference the Python documentation for --prefix:

http://docs.python.org/2.7/install/index.html#alternate-installation-unix-the-prefix-scheme

On Nov 30, 2012, at 04:37 PM, Ian Campbell wrote:

What this bug is about is what happens when I build a 3rd party module
for use with the system Python using --prefix=/usr.

In this case the modules are installed
to /usr/lib/python2.7/site-packages/ even though I built against the
system Python.

This means that the system Python doesn't see the module which I built
for it.

I can interpret the referenced documentation in two ways.

On first reading of Python's prefix scheme, it seems that using --prefix=/usr
only should indeed install into site-packages.

But the documentation also says this:

Incidentally, the real reason the prefix scheme is important is simply
that a standard Unix installation uses the prefix scheme, but with
--prefix and --exec-prefix supplied by Python itself as sys.prefix and
sys.exec_prefix. Thus, you might think you’ll never use the prefix scheme,
but every time you run python setup.py install without any other options,
you’re using it.

Given that the system Python's sys.prefix and sys.exec_prefix are both /usr,
then you could reasonably expect these two commands to be the same:

$ python setup.py install
$ python setup.py install --prefix=/usr

and of course, they are not. It's not just {dist,site}-packages that are
different but that the former uses /usr/local by default.

[2] Which I personally think is a bit suspect since IMHO only Debian
packages should be used with the system Python

I wholeheartedly disagree with this. It is entirely reasonable for users
to want to use a simple 3rd party module with the system Python without
having to rebuild the whole Python system (including all the modules
they use which *are* in Debian) from source.

They don't have to rebuild the whole Python system of course. You can use
`virtualenv --system-site-packages` and then just build the special stuff into
the virtualenv. Everything else, you get from the system.

The reason I don't favor installing 3rd party packages into /usr outside of
the packaging system is that it becomes much more difficult to manage your
Python system when you do this. What if you find that the newer Xen (or one
of its automatically installed dependencies) breaks your system? How do you
uninstall things and get back to a clean state?

Sadly distutils doesn't really provide package management support so without
the Debian packaging system, you can't really be certain you've cleaned things
up properly.

In a very real sense then, if you do this, you're own your own, and you
probably have more to worry about than adding --install-layout=deb or removing
--prefix and letting things get installed into
/usr/local/lib/pythonX.Y/dist-packages. As you note, the latter would still
be importable by your system Python, but is definitely much easier to clean
up after.

- and why not use virtualenv or a
from-source build of Python?

It is unreasonable to expect users to have to build Python from source
just to do a build of a newer version of Xen (or any other python
module) than is packaged in Debian.

As I've mentioned, there are other workaround that I would *personally*
recommend (e.g. virtualenv), but one thing is also not clear to me. From your
original bug report:

Removing the --prefix=$(PREFIX) results in installation into
/usr/local/lib/python2.7/dist-packages/ which is in the sys.path (so
correct in that sense) but doing this in the Xen tree removes the
option for people to install Xen to an alternate prefix (e.g. I think
NetBSD uses --prefix=/usr/pkg or some such).

Why couldn't you change the Xen build system to look something like this:

$(PYTHON) setup.py install $(PREFIX)

and leave $PREFIX empty by default? Then you'd get acceptable behavior on
Debian, and leave open the possibility for NetBSD users to provide
`PREFIX=--prefix=/usr/pkg`.

Also, why doesn't NetBSD do the right thing with no --prefix?

signature.asc
Description: PGP signature

Bug#694564: pep8: Support Python 3

2012-11-27 Thread Barry Warsaw

Package: pep8
Version: 1.2-1
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear Maintainer,

Upstream package already supports Python 3, such that you can do:

$ python3 -c 'import pep8'

It would be nice to get a Python 3 compatible pep8 package into Debian
as well.  I think it would be pretty easy, and I'm happy to contribute
a patch, but there's one small detail to work out.

Most Python packages are named python-foo so it's easy to add a
python3-foo version, which is the current recommendation.  However,
this binary package is just 'pep8'.  Should we name the Python 3
version python3-pep8 anyway?  Should you rename pep8 to python-pep8?
Or maybe the pep8 package would be just the executable, with
python-pep8 and python3-pep8 being the libraries.

What do you think?

- -- 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 pep8 depends on:
ii  python2.7.3~rc2-1
ii  python-pkg-resources  0.6.24-1
ii  python-setuptools 0.6.24-1
ii  python2.6 2.6.8-0.2
ii  python2.7 2.7.3~rc2-2.1

pep8 recommends no packages.

pep8 suggests no packages.

- -- no debconf information

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

iQIcBAEBCAAGBQJQtRvoAAoJEBJutWOnSwa/qvYP/jWNwG3u9pRcj3XEsmarepAy
jzRwkC77b5TSEXY/tePN6kgtasfLyliofocyGqAbz6NedEVtwnxhqZ6eNQB+5Z+C
UmLfyIGa9pgsq8i0pmPCgc0c/7nEfUHjBHDNVgaADpdgWGnRbDkiIH9SjEvYsr+Q
vONDWtFFVAsC0Xnc9CE7f/Plmt+/csNsXiIn2JLFn4NLSpzeQTuNu+/Qx4+SB/dv
28LmbJDGsIQpd7jR8KyWfChq35x9oXzHDn43jKE5d0Os9QRWQmrmNc8S2+PwMGRP
hB6tlwdWuBfmD9ZHk0ErB2DUMsaQ0D31cXhTDfsrA6NjakoAGu6AJHLcj7i5Aufg
7vOgfdQzb5FtJRm543iWuQfHvZlk6N+Rv7QdO7peyMq20vV4I+R+jZjkvJbIg9yb
bMmtzn3zzuG071AL8O5N8FJnZ/pb8EC+72lutw9kzbe/kcH+FPnmSXxHekEk/4yy
ZEstcWRxgEHGQAccJIfnXQW/I9Zo9O2InWhYSIqrnPb8sZyCMqXvSHeA0BQLuCcI
KWX9iYQLF6cgGtYygcTjrVL4x3bdw5p37Gin6pxWe648D65H85F9PFqHrTGZzhYk
2QUsn9uz+X2CpIZff71CWXqs5Cg4yLo9t79HJwIMlWhtqjLtMYOHhKzAkdqD23+y
EeaB72MpAJqMpmWaaNRS
=Rf1S
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#683053: (no subject)

2012-11-14 Thread Barry Warsaw

I understand that there are issues with 2.7.3 final, some but not all of which
are resolved.  I would personally prefer to see 2.7.3 final in Wheezy, as it
will provide a stable base release which ought to be common across different
distros.

Better I think to unblock 2.7.3-5 (now, in sid) and file rc bugs for any
failures that might still exist.


signature.asc
Description: PGP signature

Bug#664759: (no subject)

2012-11-09 Thread Barry Warsaw

Okay, I did a bit more work on the packaging and svn-injected it into the
python-apps svn repo:

http://anonscm.debian.org/viewvc/python-apps/packages/tox/

I'll ask for a review/sponsorship from debian-python.

Thanks Bradley for laying out the start of the packaging!



signature.asc
Description: PGP signature

Bug#692602: python3-requests: Upgrade to new upstream version 0.14.2

2012-11-07 Thread 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-


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#692602: (no subject)

2012-11-07 Thread 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

Bug#692602:

2012-11-07 Thread 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

Bug#691509: python-zope.interface: Upgrade to zope.interface 4.0.1

2012-10-26 Thread Barry Warsaw

Package: python-zope.interface
Version: 3.6.1-3
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear Maintainer,

wheezy/sid currently has zope.interface 3.6.1, but this is over two
years old.  One specific problem is that this version is not
compatible with Python 3.3 because of LP: #900906, which is fixed in
zope.interface 4.0.0.  The current latest version on PyPI is 4.0.1 so
it would be good to upgrade to that version.  There are a lot of
reverse dependencies though, so upgrading z.i could entail upgrading
other ZTK packages.  I have not yet done that analysis.


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

Kernel: Linux 3.5.0-17-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-zope.interface depends on:
ii  libc6 2.15-0ubuntu20
ii  python2.7.3-0ubuntu7
ii  python-pkg-resources  0.6.28-1ubuntu2
ii  python2.7 2.7.3-5ubuntu4

python-zope.interface recommends no packages.

python-zope.interface suggests no packages.

- -- no debconf information

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

iQIcBAEBCAAGBQJQirXHAAoJEBJutWOnSwa/HToP/0kbMSTzRaD12igbBbtSjRdZ
XtScR2sR3Oq2D3bYZgotW4qhmm+B+l9uI7ZCGyc09XO1Z9oscN62gLMRXvJ9sDrG
e3heREOrRknfuueZuZi0+qqWfUszro1PB/8oEt7jT6L5SYglkNdlb6z1g8Qqmevj
X7mjqRIVSqmwk9ZCd4eqOOy9RqGqLEzC/h9ishYHPUFIi7ZkGus5Q6CVd2ou/wd4
JbF+IelYnG/yXTOSDADIpixujJkkmoHVPIPBAT50TOZmkG6vlpZGnPvEy0yDPe5F
OIs6MP7minzKIf7pcn85G4AhjxwAP0t7XS3Y3G7dtshGSo0KTLiiPyatVuWy0W3U
EO3nxFKLWbQJiyJ6yNhCZ1z1UtBEObplYXntfgtljoYhA8I00Jey4ctRgzY/Tb9q
+gwoiKN+WJ9UIeJBL/pl8IE6SAaJEFyjgTEkopMolzu9RL46UIUsTpNcixrXtuzw
JF4Z7EC4dRx2062lwuGBHh7O38XxhHpSvZlk9XQEVsWQvNn4eNopG1D+JgKQDGgN
wuXKaEW7icH1j5RlQqHETbYnT8LrGcxKmzWtlLjDvdgQ4j/HjzhmVfONxQ+3hfSN
GLlE7IjcnGVztvvgcbYdFdz9Ckt2pyZ+UlNRAtlJySSCOy+Rrp283yNKYN/JXA+E
cv/7ygjLa2h02jwP70R0
=2YKh
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#691509: (no subject)

2012-10-26 Thread Barry Warsaw

Tracking this in Ubuntu as LP: #1071845

https://bugs.launchpad.net/debian/+source/zope.interface/+bug/1071845


signature.asc
Description: PGP signature

Bug#690575: python-coverage: upstream coverage supports python 3

2012-10-15 Thread Barry Warsaw

Package: python-coverage
Version: 3.4-3
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear Maintainer,

When bug #635476 is addressed (new upstream version), please also add
support for Python 3, which upstream coverage supports.


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

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

Versions of packages python-coverage depends on:
ii  libc6 2.13-35
ii  libjs-jquery  1.7.2+debian-2.1
ii  libjs-jquery-tablesorter  6-1
ii  python2.7.3~rc2-1
ii  python-pkg-resources  0.6.24-1
ii  python2.6 2.6.8-0.2
ii  python2.7 2.7.3~rc2-2.1

python-coverage recommends no packages.

python-coverage suggests no packages.

- -- no debconf information

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

iQIcBAEBCAAGBQJQfFeYAAoJEBJutWOnSwa/8isQAIYodcBfsMdRHVpCbEvS6s1v
3QwY0WvMsVubreU3ZpxD11SM4OzRbvkOWXkNypB+2vtqSqSZ3kMYon6F2thP4O4M
2+XZCmMJMIYxDtY4COxI7rGOtYtNN8rPKJ5kGEN9391YBZPiE/ZldFaXxze6bZkb
oyydgVmCzVyGQM1vjsT6uNynwNgaDvakcIiJYUb+WAKX6APsdfL8Z9Dmvo2i3cRT
PfSOUbdrrH+yVQuNLSqOw8Wyekq2hII4G45t/PZe/i4EKKw3fi2sCyWm95p2dG9S
TAsLkOioDSIZ+gSYbi5qHMfWi7/1Pdo2kHowC7MabfprtcfQs+PPKCn1qkr837kI
NiCgVSDEHGUFufq2ckntdTTZzWyTYQuEgAWwxRhQBQlYjWRv/gN6nD6p9GlAC1XA
iRQKjeVoclT3FZJDZ5E0uMj/SvlwZj/N0w3ykONF/5hqdxJX2gkw4KAm+VMhpFcg
eGOOCZr5K3/5NZotPubzoGMVnihRhv7InkEoRX8S6xjPOx6uP6qkQ1ahPGqO3Nn5
wgAFT4Tcqv98WIk/0n5G9YHUxly6IvwR3/6yHvgtGLxHxroJf8+0qxedTvjSzCm3
vP6PVLqKQzJWqSWBSqgWmRa7pCYvmrGPLY/pI3yGoKpcZctIiGQA5HPF1nfbNTkw
buvn6o3Wi699NPJQKpQZ
=0Pf/
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#690259: python3: 'make tests' uses wrong executable

2012-10-11 Thread Barry Warsaw

Package: python3
Version: 3.2.3-5
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear Maintainer,

In the top level directory of the source package, run this:

$ make tests

This will fail because 'nosetests-3' is not a valid executable.  It
should be nosetests3 (from the python3-nose package).


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

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

Versions of packages python3 depends on:
ii  python3-minimal  3.2.3-5
ii  python3.23.2.3-2

python3 recommends no packages.

Versions of packages python3 suggests:
pn  python3-doc  none
pn  python3-tk   none

- -- no debconf information

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

iQIcBAEBCAAGBQJQdw9iAAoJEBJutWOnSwa/ITUP/1Kajh00Z03ENiTn/2Yds3Zp
K9qcjx9H8fhK/+T/bkBjVKszw/9nWt7sXk6L1bWHLaip9bDbr47PYqpsrQ8xQdAh
aHASv7emF8+9mMFH85vzPqxjg2JxCQJPJEgtDi9G8BVICLDTg4U5Gm5v2q5JZf0R
cd9/aooOOUv7XsYOmt2tUYPMVqXXCWXAa9pTjIR9TWJSE+ayrW4cEnI4hDalA6Au
SpEQD34Lvg9jFJuSDBxb61iV3tDTxNfzxMCkQisBGb6Q3KSbAo6kP9OiuXANqUQh
gNBkolxrCLlifzk3t+BBZtiZSFMwlXc64wlnyW0O+MdS/pF2w8dWjRECSWa1BBRT
Gw1adro33Mas2TNwN7fnoLYXzcUrP+l1wtRe5cCuKKRVu8B6WVkbZfKD77RJV1Jd
cL9oIvyt8iXKJMZy/cam2jQe70IsG9GzKUgnZ35ZD+yVwBoRUyiP7fqYJXFtIo6U
Lx4l974rwsJiFSVYb+8l7uXiH9cdYb7Db/Sf6QAIwdjSz6FhebDVBNru4gD8jj+R
ODgcPT3X3B9AQHj1/brhul+LuY5hASWLtfKuxYwRN2PxD4n3dph/CNEfWE7xHXDV
8aeBpBjtYpT+pWm7Fujvw6DlhYpumKDPwyWhYWMQ2zlAfZ26RuDa59yWZgwuFb1E
+XEUke9eRQ+HDWjgPgcR
=aHqG
-END PGP SIGNATURE-
=== modified file 'Makefile'
--- Makefile	2012-06-30 19:32:37 +
+++ Makefile	2012-10-11 18:22:32 +
@@ -35,7 +35,7 @@
 
 # TESTS
 nose:
-	nosetests-3 --with-doctest --with-coverage
+	nosetests3 --with-doctest --with-coverage
 
 tests: nose
 	make -C tests

Bug#672178: dh_python3: not ready for Python 3.3

2012-10-11 Thread Barry Warsaw

Package: python3
Version: 3.2.3-5
Followup-For: Bug #672178

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear Maintainer,

The attached patch fixes both bug 672178 and 690259.  It should allow
python3-defaults to be compatible with Python 3.3 now.


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

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

Versions of packages python3 depends on:
ii  python3-minimal  3.2.3-5
ii  python3.23.2.3-2

python3 recommends no packages.

Versions of packages python3 suggests:
pn  python3-doc  none
pn  python3-tk   none

- -- no debconf information

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

iQIcBAEBCAAGBQJQd0bXAAoJEBJutWOnSwa/51kP/2T6pYPY65NLDuON4VH8JlYy
uR017VxOGPbaLR++ahZorjawoiQxqtfWAsjnrB61of/xGt3ixz20/hDkB5TEyFF5
WOHv87cxTNaFMbKbetX6WDUg2FXI8pQtb2sLt9iBH7JjY5S6yp1pztfrG2L1q3ra
Relqi59ChmI2W5F1qSkVRDiMHtkGnag6J2um5+RJ09vFHdw+MlwrvO5gt/LJyFAB
qu5c1K0uIu744WQMdRbsz7O+Rq5QqAKqPmwcAzPLZ7tOC+iOJJE6V+vNdi32h2V6
HFyisGcIcEO0c+mrEy/wdqzhJRSRdsNgbvOFG+6PMhX/T2MOGP7BWfhPq61AvEGv
GsN+vlM3yEY5oRKG+bfHWhTKf76+6PDh8ET18YXw44YT2itTnQ3DU12dy1s8RZxg
lh/cRgagNE5ku7vIto7SPsO3QqotXN6zabrz5k4NTEjj0oR+TDjsbQftiRsNNOSj
A5515TGRK0l7yyeRTakWWU4jLbmTk1xmYhDHyEwNsgT9Sedq7R3BgE8MDONwXOt0
fXhAmaUXEQjbisLJCS76YCXeEVU0sO7cb+zMEXoLevX4jsglXFLIwGJ43LPSenZ8
PWGFBxwfs7XasH1YxKcHMJib395jUTrVdkc8YBSYiwZPB7jGQ8zG4DeTMydUjXIF
hJPgq9KZZHrAix5FIB63
=hf+j
-END PGP SIGNATURE-
=== modified file 'Makefile'
--- Makefile	2012-06-30 19:32:37 +
+++ Makefile	2012-10-11 19:08:03 +
@@ -35,7 +35,7 @@
 
 # TESTS
 nose:
-	nosetests-3 --with-doctest --with-coverage
+	nosetests3 --with-doctest --with-coverage
 
 tests: nose
 	make -C tests

=== modified file 'README.derivatives'
--- README.derivatives	2011-03-13 22:13:08 +
+++ README.derivatives	2012-10-11 21:33:21 +
@@ -1,7 +1,8 @@
 How to change a list of supported Python versions?
 ~~
 
-* Open debian/debian_defaults file and change `supported-versions` variable
+* Open debian/debian_defaults file and change `supported-versions` variable,
+  separating multiple values by comma
 * Open debian/control.in file and edit python3-all, python3-all-dev and
   python3-all-dbg's Depends line (add or remove pythonX.Y packages)
 * Open debpython/versions.py file and edit `SUPPORTED` list around
@@ -14,8 +15,6 @@
 * Open debian/debian_defaults file and change `default-version` variable
 * Open debian/rules file and edit `VER` variable (default version), `NVER`
   (default + 1 version) and `PVER` (default version with python prefix)
-* Open debian/py3versions.py file and edit `debian_default` variable around
-  line 171
 * Open debpython/versions.py file and edit `DEFAULT` variable around line 27
 
 

=== modified file 'debian/changelog'
--- debian/changelog	2012-09-19 22:17:51 +
+++ debian/changelog	2012-10-11 21:44:11 +
@@ -1,3 +1,17 @@
+python3-defaults (3.2.3-7) UNRELEASED; urgency=low
+
+  * dh_python3: Rework calculation of extension tags to add support for
+Python 3.3's different suffixes, and to allow for unadorned .so files
+to assume they are built with the default Python 3 version.
+Closes: 672178
+  * README.derivatives: It is no longer necessary to edit
+debian/py3versions.py since the values are taken from
+debian_defaults.  Also added some text on how to separate the
+specification when multiple versions are supported.
+  * Makefile: Fix the nosetests3 command.  Closes: 690259
+
+ -- Barry Warsaw ba...@python.org  Thu, 11 Oct 2012 15:09:02 -0400
+
 python3-defaults (3.2.3-6) unstable; urgency=low
 
   [ Piotr Ożarowski ]

=== modified file 'dh_python3'
--- dh_python3	2012-06-30 19:15:05 +
+++ dh_python3	2012-10-11 19:04:38 +
@@ -47,9 +47,17 @@
 log = logging.getLogger(__name__)
 os.umask(0o22)
 
-# tag that will be added to .so files without one
-EXTENSION_TAG = 'cpython-%smu'
-DBG_EXTENSION_TAG = 'cpython-%sdmu'
+# Tag that will be added to .so files without one.  Because these values are
+# different between versions of Python 3 (e.g. 3.2 has dmu but 3.3 only has
+# dm), this maps vrepr()'s to extension templates.
+EXTENSION_TAGS = {
+'3.2': 'cpython-%smu',
+'3.3': 'cpython-%sm',
+}
+DBG_EXTENSION_TAGS = {
+'3.2': 'cpython-%sdmu',
+'3.3': 'cpython-%sdm',
+}
 TAG_RE = re.compile(r'-([0-9]{2})[^-.]*\.so$')
 
 # naming conventions used in the file:
@@ -132,17 +140,23 @@
 ### PACKAGE DETAILS 
 def tagged_extname(fname, version, dbg_package=False):
 Return tagged extension name for given file  version.
-vers = vrepr(version)  # make sure it's a string
-vers = vers.replace('.', '')
+extkey = vrepr(version)  # make sure it's a string
+vers = extkey.replace

Bug#672178: (no subject)

2012-10-11 Thread Barry Warsaw

Apologies for the syntax error in the Closes text.


signature.asc
Description: PGP signature

Bug#572072: (no subject)

2012-10-10 Thread Barry Warsaw

For all intents and purposes, computer-janitor is abandonware.

https://bugs.launchpad.net/ubuntu/+source/computer-janitor/+bug/1050071


signature.asc
Description: PGP signature

Bug#674083: debian/rules style for python-tz

2012-10-08 Thread Barry Warsaw

Apologies for not responding sooner, this one got buried in my inbox.

On Sep 19, 2012, at 05:41 PM, Thomas Kluyver wrote:

I think Barry's key suggestion was to avoid using for loops to handle
multiple versions of Python 3. The example in LibraryStyleGuide uses
rules like this:

build-python%:
python$* setup.py build

override_dh_auto_build: $(PYTHON3:%=build-python%)
dh_auto_build

CCed Barry in case he wants to offer other suggestions about
modernising d/rules.
For reference, the current d/rules file in Debian is here:
http://anonscm.debian.org/viewvc/pkg-zope/python-tz/trunk/debian/rules?view=markup

I happen to like this style over the explicit for-loop because it's more
succinct, and lets make do the hard lifting.  It's easier to describe to
folks, and easier to cargo cult, so I think in general it makes for less
problematic d/rules files.

Functionally, the two styles achieve the same results, so it's hard to argue
on that point.  Several of us debian-python folks settled on the current
recommendations after much discussion in various forums, including tracker
issues.

Of course, the decision about which to use is always up to the maintainer,
however I still personally recommend the LibraryStyleGuide version for Debian
Python packagers.

Cheers,
-Barry

And yep, I can't wait for python-multibuild ;).  Maybe we need to get dh
support for Python 3 in the meantime?


signature.asc
Description: PGP signature

Bug#661441: (no subject)

2012-10-02 Thread Barry Warsaw

I added a merge proposal on the Ubuntu bug which fixes the FTBFS (and adds the
`set -x` flag in d/rules).  I'm not sure upstream would approve of the patch,
since it's not clear to me whether the bogus SCRIPT tag should be entirely
stripped or not.  But in the absence of upstream response to their bug, this
does fix the FTBFS.

Here's the Ubuntu bug:

https://bugs.launchpad.net/ubuntu/quantal/+source/genshi/+bug/935516

and the merge proposal with the diff:

https://code.launchpad.net/~barry/ubuntu/quantal/genshi/lp935516/+merge/127596


signature.asc
Description: PGP signature

Bug#689327: python-mode: Update copyrights

2012-10-01 Thread Barry Warsaw

Package: python-mode
Version: 1:6.0.12-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

$ debdiff python-mode_6.0.10-1.dsc python-mode_6.0.12-1.dsc | grep -i
copyright  
+;; Copyright (C) 2009,2010 Joao Tavora
+;; Copyright (C) 2012  Urs Fleisch
+;; Copyright (C) 2012  Urs Fleisch
+;; Copyright (C) 2004, 2005, 2007, 2008, 2009 William Xu
+# Copyright 2005-2007 Matt Mackall m...@selenic.com


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

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

Versions of packages python-mode depends on:
ii  emacs23 [emacsen]  23.4+1-4
ii  python 2.7.3~rc2-1

Versions of packages python-mode recommends:
pn  pychecker  none
pn  pymacs none

Versions of packages python-mode suggests:
pn  pylint   none
pn  python-ropemacs  none

- -- no debconf information

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

iQIcBAEBCAAGBQJQabx1AAoJEBJutWOnSwa/JVYP/j8G0chzmOPprtHvcfXnaP5T
Nh+Zt9RM42KMDTJ1EM+o7ubzVGYrpO9WbxBJwJ15Gx+qwI070C32GxdV45jOF0XF
yyZRCTaSjwXKiXMAfTYWiV8NOUCkVGgXLj1TJXlLF48U0BCqOHJ7q9tFqPZc0DSw
FfzPNfkcjin5yV0kyRJMTsowRDxuN772AY0fV41+39NX8YAmKEJgdndtE/pTuXCJ
d68+IFZtD3LzxY++kE3fSfBmwUNlDHAwenPjdgoTEDfsJY2lR8287Vpyk9fSfUsZ
wzTDAELWUBz3WMKqoR5FCTYnV3+k/d5Mqw3B5BMT54mNP1ym+O4244jeQ0Bwb9Wv
jEaMcIJKRvTa7NwbRrasr91G9WMfTriLwEVe3xYtQt15XJRsAzoEMoEW1bjDT8A5
JDFKeFKK5HcAmFNquQcErn0mdTmVUuVF/B2DW13WnsuJNLJZWWtAOXO/cXr5Vgfq
tu4/eWSP0xh0n7bXU34FPuwSKFFWk310CF6DuTh77m72JrP02xxfIQNHPAgJZHDp
uXoJBWuDXax7Ea0TZ2mu23qmFXTmCZK5GWQ6lEy4FpM6oUYbUkqMw1yX3IruSpy4
AKtkDDnoJRLNSuVfQxjnZ1+yLKdX9pWUek/FuBuG03MVzBrvtxtbA+bPE2PRztlZ
o557J2CiqU0k53nYd3zb
=LHO+
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#681502: (no subject)

Submitted to upstream at

https://bugs.launchpad.net/debian/+source/python-mode/+bug/1058261

As mentioned in the upstream bug, when testing my soon-to-be-uploaded 6.0.12
package on unstable with `emacs -q`, I see the following differences:

* Jumping to the end of the file shows me proper syntax highlighting.
* While scrolling up does stall, emacs eventually responds to C-g


signature.asc
Description: PGP signature

Bug#328894: (no subject)

I cannot reproduce this with python-mode 6.0.12 (soon to be uploaded).  Is
this still a problem for you?


signature.asc
Description: PGP signature

Bug#329234: (no subject)

In python-mode.el, when I crash the sub-interpreter, I see this:

-snip snip-
Python 2.7.3rc2 (default, Apr 22 2012, 22:30:17) 
[GCC 4.6.3] on linux2
 import ctypes
 i = ctypes.c_char('a')
 j = ctypes.pointer(i)
 c = 0
 while True:
...  j[c] = 'a'
...  c += 1
... 

Process python segmentation fault (core dumped)
-snip snip-

which seems good enough to me.



signature.asc
Description: PGP signature

Bug#680578: (no subject)

Is XEmacs even still available in Wheezy?

% aptitude search xemacs
% sudo apt-get install xemacs21
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Package xemacs21 is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source

E: Package 'xemacs21' has no installation candidate
% lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:Debian GNU/Linux testing (wheezy)
Release:testing
Codename:   wheezy


signature.asc
Description: PGP signature

Bug#680577: (no subject)

I'll add the requested skip in 1:6.0.12-1, but I can't test it as I don't have
emacs21 installed and it's not available in Wheezy.  At least the skip doesn't
seem to break installation on emacs23 :).


signature.asc
Description: PGP signature

Bug#657395: RFS: cinnamon/1.5.2-1 [ITP] -- Innovative and comfortable desktop

2012-09-27 Thread Donald J. Barry

May I strongly request that a DD sponsor cinnamon (and muffin) so that
it is in Wheezy?  Many of us, long time Debian advocates and
ambassadors, simply do not desire to move from GNOME2 to (vanilla)
GNOME3.  Cinnamon is a critical package to preserve efficiency and our
workflows within GNOME3.

It would really be a shame to drop the ball on this -- this is one bit
of choice that I think is quite essential for Wheezy, and deserves to
get in despite the freeze.

Cheers,

-Don


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#685167: py3clean removes *.pyc of foreign packages

2012-09-19 Thread Barry Warsaw

On Sep 19, 2012, at 07:20 AM, Dmitry Shachnev wrote:

@Scott: please merge Barry's branch :)

I also think we should use a different version number (something like
3.2.3.6) to fix bug #684431.

Piotr mentioned he was going to try to get to it today.



signature.asc
Description: PGP signature

Bug#685167: (no subject)

So I agree that this is a legitimate bug, and the patch does appear to fix the
problem, at least in the use case given.  I'm just not sure it does it in the
right way.

I'm confused by a few things in the original code.  Looking at the docstring
for destroyer() we see:

Remove every .py[co] file associated to received .py file.

:param magic_tag: if None, removes __pycache__ directories,
if False, removes python3.1's .pyc files only,
otherwise removes given magic tag from __pycache__ directory
:type magic_tag: None or False or str

Dmitry's patch changes this documented behavior because when magic_tag=None,
it will *not* remove the __pycache__ directory if that happens to be
/usr/lib/python3/dist-packages.  So if the patch is accepted, the docstring at
least has to be updated.

(Aside: if you really wanted to remove the entire __pycache__ directory and
everything in it, I wonder why one call to shutil.rmtree() wasn't used
instead?)

(Aside2: imp.cache_from_source() would give you the tagged .pyc file to
remove, but i guess of course the problem is that the version of Python 3
running py3clean won't necessarily match the version of pyc files you want to
clean up.  Still, I might use imp.cache_from_source() first, then split the
basename and substitute for the tags, or glob for the tags part of the
resulting file name.)

destroyer()'s documented behavior only makes sense when you're dealing with a
private package.  Otherwise, for public packages, it should never be correct
to remove the __pycache__ directory and all its contents.  An empty
/usr/lib/python3/dist-packages/__pycache__ shouldn't ever hurt.

Unfortunately, py3clean doesn't know whether it's dealing with a private or
public package.  I don't think `-p package` gives it enough information,
though perhaps there's a way to find out from the package name that I'm
missing.

The other thing I'd do is instead of hard-coding python3/dist-packages, I'd
probably compare the resulting directory against the list given by
site.getsitepackages():

 import site
 site.getsitepackages()
['/usr/local/lib/python3.2/dist-packages', '/usr/lib/python3/dist-packages', 
'/usr/lib/python3.2/dist-packages', '/usr/lib/dist-python']

If the directory being cleaned were any of these, then don't empty them out.

So I guess if no one else has any other suggestions, then the following
changes should be made to the patch, after which it could be applied:

* compare against site.getsitepackages() for directories that should not be
  removed.
* update the docstring to indicate that site package directories are not
  removed even if magic_tag is None


signature.asc
Description: PGP signature

Bug#685167: py3clean removes *.pyc of foreign packages

On Sep 18, 2012, at 07:37 PM, Dmitry Shachnev wrote:

On Tue, 18/09/2012 11:05 -0400, Barry Warsaw wrote:
 So I guess if no one else has any other suggestions, then the following
 changes should be made to the patch, after which it could be applied:
 
 * compare against site.getsitepackages() for directories that should not be
   removed.
 * update the docstring to indicate that site package directories are not
   removed even if magic_tag is None

Done, the updated patch attached. Thanks for the suggestions!

Also, I've updated my branch at lp:~mitya57/+junk/python3-defaults so
that it can be easily merged.

Thanks for making the changes.  Note that the above branch has some other
changes which aren't related to this bug.  I'm disinclined to include those
fixes here for that reason, and also because i think there are better ways to
do it, e.g. by using a context manager to handle the automatic closing of the
files, instead of relying on potentially buggy explicit .closes()



signature.asc
Description: PGP signature

Bug#685167: py3clean removes *.pyc of foreign packages

On Sep 18, 2012, at 07:37 PM, Dmitry Shachnev wrote:

On Tue, 18/09/2012 11:05 -0400, Barry Warsaw wrote:
 So I guess if no one else has any other suggestions, then the following
 changes should be made to the patch, after which it could be applied:
 
 * compare against site.getsitepackages() for directories that should not be
   removed.
 * update the docstring to indicate that site package directories are not
   removed even if magic_tag is None

Done, the updated patch attached. Thanks for the suggestions!

Also, I've updated my branch at lp:~mitya57/+junk/python3-defaults so
that it can be easily merged.

I'll commit this to alioth bzr after I do some additional local testing, but
it generally looks pretty good.  Thanks!  I made a few minor changes, such as
using os.path.splitext() instead of assuming the extension is 3 characters
long (it probably always will be, but splitext() is safer).  I also added a
bunch of comments so that it's clearer what's going on.

I'll have to request sponsorship since I can't upload this myself.



signature.asc
Description: PGP signature

Bug#685167: py3clean removes *.pyc of foreign packages