RFS: python-django-voting
Hello mentors, I am looking for a sponsor for my package "python-django-voting". Package name: python-django-voting Version : 0+svn73 Upstream Author : Jonathan Buchanan URL : http://code.google.com/p/django-voting License : MIT Programming Lang: Python Description : generic voting application for Django It builds the binary package: python-django-voting The package has already been partly reviewed by a Debian developer (and amended by myself). The DD unfortunately had to end his sponsorship due to time constraints. The upload would fix this bug: 581833 My motivation for maintaining this package is: I'm interested in getting Django apps packaged for Debian; particularly Pinax dependencies. Package location(s): - Svn: svn://svn.debian.org/python-modules/packages/python-django-voting/trunk/ - Svn-Browser: http://svn.debian.org/viewsvn/python-modules/packages/python-django-voting/trunk/ - PythonModulesTeam queue: http://wiki.debian.org/Teams/PythonModulesTeam/TODO I would be grateful if someone sponsored this package for me. Kind regards, Bernhard signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
RFS: python-django-threadedcomments
Hello mentors, I am looking for a sponsor for my package "python-django-threadedcomments". Package name: python-django-threadedcomments Version : 0.5.2 Upstream Author : Eric Florenzano URL : http://github.com/ericflo/django-threadedcomments License : BSD Programming Lang: Python Description : simple yet flexible threaded commenting system for Django It builds the binary package: python-django-threadedcomments The package has already been partly reviewed by a Debian developer (and amended by myself). The DD unfortunately had to end his sponsorship due to time constraints. The upload would fix this bug: 580815 My motivation for maintaining this package is: I'm interested in getting Django apps packaged for Debian; particularly Pinax dependencies. Package location(s): - Svn: svn://svn.debian.org/python-modules/packages/python-django-threadedcomments/trunk/ - Svn-Browser: http://svn.debian.org/viewsvn/python-modules/packages/python-django-threadedcomments/trunk/ - URL: http://revu.ubuntuwire.com/p/python-django-threadedcomments - dget: http://revu.ubuntuwire.com/revu1-incoming/python-django-threadedcomments-1009220127/python-django-threadedcomments_0.5.2-1.dsc - PythonModulesTeam queue: http://wiki.debian.org/Teams/PythonModulesTeam/TODO I would be grateful if someone sponsored this package for me. Kind regards, Bernhard signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [DebianGIS] Re: thuban strict wxPython version check?
On Fri, Jun 09, 2006 at 09:10:01PM +0200, Francesco Paolo Lovergine wrote: > On Thu, Jun 08, 2006 at 05:22:33PM +0200, Bernhard Herzog wrote: > > Paul Wise <[EMAIL PROTECTED]> writes: > > > > > I'm wondering what the following check from Thuban/version.py is for? Is > > > the wxWidgets ABI really so fragile that wxProj breaks on new minor > > > 2.6.X versions or new 2.4.X versions? Surely using the soname to do > > > version checks with the normal shared library support is enough? > > > > The symptom people often see when using Thuban with a different > > wxWidgets version -- even when it's only a different minor version -- is > > that it segfaults as soon as it tries to actually render a map on the > > screen. In the past there were enough problem reports from users about > > this for us to put in the version check so that users would at least get > > a meaningful error message instead of just a segfault. > > > > The reason for the crashes is that wxproj accesses wxPython objects at > > the C++-level to extract the corresponding wxWidgets object so that it > > can call wxWidgets methods directly. That way, Thuban can render data > > read from e.g. a shapefile without having to funnel the data through > > Python which improves rendering speed considerably. > > > > Unfortunately, this means that the wxWidgets object used by wxproj has > > been created by the wxWidgets library wxPython is linked with and that > > may be different from the one wxproj is linked with. The libraries may > > differ in the layout of the classes and/or virtual tables depending on > > the version and perhaps compile time options. > I'm not a python addicted, but I suspect this issue should be managed > at python-wxgtk2.4 level. Note that wxproj is a package that currently comes with Thuban. Obviously is cures a weakness of wx and wxPython, but the fix might be a major effort, this is why wxproj is helpful. > Incompatibilities in ABIs should be managed > using different source packages to avoid conflicts. I think we are grateful for hint on how to improve the current situation without major hassle. One idea to be evalutated could to be make a wxproj package seperate from Thuban, which would limit the dependecies I assume. > I'm CC to d-python > list for analysis... If there are hints, please also give them to thuban-devel. Thanks, Bernhard signature.asc Description: Digital signature
