Re: [PATCH] Support :any architecture qualifiers for multiarch
On Mon, Apr 21, 2014 at 02:41:35AM +0200, Jakub Wilk wrote: > >As a strawman, if there's a consensus that it's important to > >preserve the capability to install jessie module packages on top > >of wheezy's python, we could generate dependencies such as: > > python:any (>= 2.7.5-5) | python (>= 2.6.6-3) > >which I think would DTRT in all cases except where you try to > >cross-install on top of the wheezy python, which is a negligible > >use case. > The idea that cross-installabilty of python could justify less > smooth wheezy->jessie upgrades is not even remotely funny. This has no impact on upgrades. Why would you expect cross-installing anything as part of an upgrade? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: [PATCH] Support :any architecture qualifiers for multiarch
* Steve Langasek , 2013-09-18, 14:33: On Wed, Sep 18, 2013 at 06:24:13PM +0200, Jakub Wilk wrote: Following the “if it didn't happen on a mailing list, it didn't happen”, I repeat here what I said on IRC: 12:26 < kwilk> So I rebuilt src:python-aalib, and I ended up these Depends: "python3:any (>= 3.3.2-2~), libaa1". 12:27 < kwilk> This is wrong; the package only works if the interpreter architecture is the same as libaa1 architecture. 12:27 < kwilk> Please revert this ":any" mess. 12:30 < kwilk> In general, just because a script or a module is pure-Python doesn't mean it doesn't care about interpreter's architecture. 12:30 < kwilk> And there's no way to determine automatically whether it cares or not. Nonsense. Yeah, right. # dpkg --print-architecture i386 # dpkg --print-foreign-architectures amd64 # apt install liblas [...] # python -c 'import liblas; print liblas' # apt install python:amd64 [...] # python -c 'import liblas; print liblas' Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.7/dist-packages/liblas/__init__.py", line 2, in from core import get_version File "/usr/lib/python2.7/dist-packages/liblas/core.py", line 157, in las = ctypes.CDLL(lib_name) File "/usr/lib/python2.7/ctypes/__init__.py", line 365, in __init__ self._handle = _dlopen(self._name, mode) OSError: liblas_c.so.2: wrong ELF class: ELFCLASS32 As a strawman, if there's a consensus that it's important to preserve the capability to install jessie module packages on top of wheezy's python, we could generate dependencies such as: python:any (>= 2.7.5-5) | python (>= 2.6.6-3) which I think would DTRT in all cases except where you try to cross-install on top of the wheezy python, which is a negligible use case. The idea that cross-installabilty of python could justify less smooth wheezy->jessie upgrades is not even remotely funny. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140421004135.ga8...@jwilk.net
ITA: python-django-contact-form -- extensible contact-form application for Django
retitle 705275 ITA: python-django-contact-form -- extensible contact-form application for Django owner 705275 ! thanks Hi, I am using python-django-contact-form and I am willing to take care of the package. Cheers, Christophe signature.asc Description: Digital signature
Re: Some thoughts about py{support,central} -> dh_python2 conversion
On 12 November 2013 15:08, Jakub Wilk wrote: > * Jakub Wilk , 2012-05-03, 21:41: > >>> 2) Do not skip the "Before you begin"[0] step. This is very important: if >>> two packages share a namespace, either both or none of them must use >>> python-support. Also, it's not enough just to convert them all to >>> dh_python2: you must make sure (using Breaks or Depends relationships) that >>> you cannot co-install an older python-support-based versions together with >>> dh_python2-based ones. >> >> repoze: >> pymodules: [python-repoze.who, python-repoze.what-plugins, >> python-repoze.who-plugins, python-repoze.what, >> python-repoze.sphinx.autointerface] >> site-pkgs: [python-repoze.lru, python-repoze.tm2] > > > True positive. If you install one package from the "pymodules" set and one > from the "site-pkgs" set, the former package doesn't work. > > "python-repoze.who-plugins" is in the worst situation, as it transitively > depends on "python-repoze.lru". > I've now converted all repoze packages in the pymodules set to use dh_python2. I think it should be sufficient to resolve this set, but i will verify this again in clean chroot with packages from sid. -- Regards, Dimitri. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CANBHLUgg=t09zdehffxtss+ck67kjxfuz8hdy+wme6mdhqn...@mail.gmail.com
Request to join the DPMT
Hi, I would like to join DPMT and work on improving the team packages, mainly django modules. I intend to adopt python-django-contact-form (which got upstream improvements) and I will need a sponsor to check it and eventually upload it. My alioth login is tobald-guest. Thanks, Christophe Siraut signature.asc Description: Digital signature
