Re: Bug#798066: Multiarch-renamed python extensions not found during autopkgtest testing

2015-12-11 Thread Antonio Terceiro
On Thu, Dec 10, 2015 at 10:52:05PM -0800, Afif Elghraoui wrote:
> Hi,
> على الأربعاء  9 كانون الأول 2015 ‫05:25، كتب Antonio Terceiro:
> > autopkgtest does not do anything special wrt dependencies, it will
> > install exactly what you told it to in debian/tests/control
> [...]
> > 
> > I am therefore closing this bug.
> The problem is not that something is not installed. The problem is that
> the multiarch configuration for python is not right in autopkgtest (or
> schroot). During the package build, dh-python renames the compiled
> extension to contain the multiarch triplet. For some reason, only in
> autopkgtest, python is not properly configured to find the extension
> after it has been renamed, so autopkgtest runs requiring the compiled
> extensions fail. does not use schroot anymore, since a few weeks ago. and
autopkgtest does not do anything special to packages, it just installs
them on an otherwise regular testbed, be it a schroot chroot, an lxc
container (what currently uses), and so on.

> So should we continue to have hacks like this to get autopkgtest to find
> multiarch-renamed extensions?
> cd /usr/lib/python2.7/dist-packages/pysam
> gnutype=`dpkg-architecture -qDEB_TARGET_GNU_TYPE`
> for so in *.${gnutype}.so ; do sudo ln -sf $so `basename $so
> .${gnutype}.so`.so ; done

Again, there is nothing special in the autopkgtest test beds. I also
don't see other python packages that contain compiled extensions needing
to do this sort of thing.

I tried python-pysam here, and after some trial and error, I can also reproduce
the same issue outside of autopkgtest. The issue is that Python load path is
being confused by the fact that you are on root of the source package:

# pwd
# ls
AUTHORS  INSTALL  THANKS debian  samtools  setup.cfg  tests
COPYING  KNOWN_BUGS  README.rst   benchmark  doc pysam  
requirements.txt  save   win32
# python
Python 2.7.11 (default, Dec  9 2015, 00:29:25) 
[GCC 5.3.1 20151205] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import pysam
Traceback (most recent call last):
  File "", line 1, in 
  File "pysam/", line 1, in 
from pysam.libchtslib import *
ImportError: No module named libchtslib
# cd /
# python
Python 2.7.11 (default, Dec  9 2015, 00:29:25) 
[GCC 5.3.1 20151205] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import pysam 

So your problem has nothing to do autopkgtest, other than the fact that
autopkgtest always starts the tests from the root of the source package.

Antonio Terceiro 

Description: PGP signature

Bug#807702: ITP: django-user-accounts -- infrastructure for dealing with user accounts

2015-12-11 Thread Michael Fladischer
Package: wnpp
Severity: wishlist
Owner: Michael Fladischer 

Hash: SHA512

* Package name: django-user-accounts
  Version : 1.3.1
  Upstream Author : Brian Rosner 
* URL :
* License : Expat
  Programming Lang: Python
  Description : infrastructure for dealing with user accounts

 Provides extensible user accounts to a Django project. django-user-accounts has
 very good default behavior when handling user accounts. It has been designed to
 be customizable in many aspects.
 By default this app will:
  * enable username authentication
  * provide default views and forms for sign up, log in, password reset and
account management
  * handle log out with POST
  * require unique email addresses globally
  * require email verification for performing password resets

Version: GnuPG v1