EUREKA. I found it.
Starting on line 451 in
/usr/local/lib/python2.5/site-packages/django/http/multipartparser.py,
there is a try statement as follows:
try:
from mx.TextTools import FS
self._fs = FS(boundary).find
except ImportError:
self._fs = lambda data: data.find(boundary)
See that dreaded mx.TextTools line? That's where that reference is in
Alexandre's posts and the trouble ticket. Now if these lines are
replaced with simply:
self._fs = lambda data: data.find(boundary)
I can add groups, update users, and everything else has been causing
the core dumps when mx-DateTime is installed. I just tested it and it
worked.
Now I need to learn how to write the patch for it....
Thanks,
Ryan
On Sun, May 24, 2009 at 7:05 AM, Darrin Chandler
<[email protected]> wrote:
> Ryan & Alexandre, nice work so far!
>
> On Sat, May 23, 2009 at 05:22:36PM -0700, Ryan Boggs wrote:
>> So you are using Postgresql as you back end DB. Have you tried using
>> py-psycopg2 with Django? I've been using it for my testing without
>> problems and it doesn't seem to rely on py-mxDateTime.
>
> So it's looking as if it's not, strictly speaking, Django's fault after
> all.
>
>> Still, even though removing py-mxDateTime allows Django 1.0+ to work,
>> that's not the desired work around to get into ports, right?
>
> The best solution would be to track this down to where the problem
> really lives and fix it or work around it there. This is the only "real"
> solution. However, is it true that Django is using mxDateTime with some
> odd usage pattern that triggers this? If so then perhaps a workaround
> might be found in Django itself.
>
> But I went fishing for maintainers because I lack time: I'm no
> longer a pig here. I'm barely a chicken. So I'll shut up and let you
> people keep at it. ;-)
>
> --
> Darrin Chandler | Phoenix BSD User Group | MetaBUG
> [email protected] | http://phxbug.org/ | http://metabug.org/
> http://www.stilyagin.com/ | Daemons in the Desert | Global BUG Federation
>
