Ian, 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.
Still, even though removing py-mxDateTime allows Django 1.0+ to work, that's not the desired work around to get into ports, right? Thanks, Ryan On Sat, May 23, 2009 at 5:15 PM, Ian Darwin <[email protected]> wrote: > Ryan Boggs wrote: >> >> To Alexandre: >> Thanks for that link. I do not use py-mxDateTime normally so I never >> installed it on my test machine. Once I did, I started receiving >> those errors that both Ian and Darrin were reporting with Django 1.0+. >> py-mxDateTime contains the mxTextTools library that seems to be (at >> least) one of the factors based on the information in the trouble >> ticket link that you provided. The funny thing is that when I >> pkg_delete py-mxDateTime, Django starts working normally again with no >> dumps. >> >> And just to update everyone else: >> Since Alexandre pointed out that trouble ticket, I've been trying to >> back track exactly where the problem seems to occur. From what I can >> tell, the core dump occurs during the get_response method in >> /usr/local/lib/python2.5/site-packages/django/core/handlers/base.py. >> Upon further inspection (by printing the vars), I found that the >> problem seems to be with the request object that is passed into the >> get_response method. Also, this seems to only occur when content type >> of the object is listed as "multipart/form-data", which is probably >> why certain actions work (like adding users) and others cause the dump >> (like updating users or adding groups). >> > > Nicely spotted. Unfortunately I at least cannot remove it, since my database > driver depends on it:-) > > tiny$ sudo pkg_delete py-mxDateTime > Can't remove py-mxDateTime-3.1.2-python2.5 without also removing: > py-pgsql-2.5.1p0 py-psycopg-1.1.21p7-python2.5 > tiny$ >
