Re: [Django] #22563: Migration of admin.LogEntry.user fails.

[Django]

#22563: Migration of admin.LogEntry.user fails.
-+--
 Reporter:  efrinut@…|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  1.7-beta-2
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by melinath):

 * cc: stephen.r.burrows@… (added)


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/075.906960d3b3696a9d5a3085bde72ed47f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22480: "django-admin.py dumpdata" - unable to serialize

[Django]

#22480: "django-admin.py dumpdata" - unable to serialize
---+--
 Reporter:  yn |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:  1.6
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by yn):

 Replying to [comment:3 timo]:
 > I have been unable to reproduce this error, but could you try `python
 manage.py ...`?

 Yes, it working now

   python manage.py dumpdata > data.json

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/060.1d6a905aa1906e585fbf5ed5e39eceb3%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #9893: Filename + path length greater than 100 truncated on database insertion in Core.Storage

[Django]

#9893: Filename + path length greater than 100 truncated on database insertion 
in
Core.Storage
-+-
 Reporter:  Refefer  |Owner:
 Type:  Bug  |  pavel_shpilev
Component:  File |   Status:  assigned
  uploads/storage|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  storage, filename| Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by pavel_shpilev):

 * status:  new => assigned
 * owner:   => pavel_shpilev


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.f50385694d6aea85e3569b91bfaf31a7%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22574: BrokenLinkEmailsMiddleware: send an email for all broken links, not just 404

[Django]

#22574: BrokenLinkEmailsMiddleware: send an email for all broken links, not just
404
--+--
 Reporter:  jdufresne |Owner:  nobody
 Type:  New feature   |   Status:  closed
Component:  Core (Other)  |  Version:  master
 Severity:  Normal|   Resolution:  wontfix
 Keywords:| Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by russellm):

 * status:  new => closed
 * needs_better_patch:   => 0
 * resolution:   => wontfix
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 Thanks for the suggestion, but I don't think this is a good idea.

 Firstly, I'm not wild about the idea of increasing the volume of email on
 any existing users that have this middleware installed.

 Secondly, email notification isn't the right way to be handling this sort
 of reporting. BrokenLinkEmailsMiddleware is a big like a vestigial tail -
 it is a relic of an era when there wasn't tools like Sentry to do log
 analysis. I'd rather focus our efforts on integrating better with good
 logging and analysis tools, rather than expanding the capabilities of a
 feature that should probably be deprecated.

 Lastly, if you *really* want 403's et al to reported by email, you can do
 this in your own code without difficulty.

 If you'd like to advocate for this feature, feel free to open a discussion
 on the Django-developers mailing list.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.70d4ff1ec15b4072aadab04426739439%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #1349: MEDIA_URL and MEDIA_ROOT do not serve the files

[Django]

#1349: MEDIA_URL and MEDIA_ROOT do not serve the files
--+--
 Reporter:  lzap@…|Owner:  adrian
 Type:  defect|   Status:  new
Component:  Core (Other)  |  Version:
 Severity:  major |   Resolution:
 Keywords:| Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by anonymous):

 * status:  closed => new
 * ui_ux:   => 0
 * resolution:  invalid =>
 * easy:   => 0


Comment:

 This *still* needs documentation fixes! No where near MEDIA_* is this
 mentioned!

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/072.d219aaf2d82c480ec69b2614875dc087%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #22574: BrokenLinkEmailsMiddleware: send an email for all broken links, not just 404

[Django]

#22574: BrokenLinkEmailsMiddleware: send an email for all broken links, not just
404
--+
 Reporter:  jdufresne |  Owner:  nobody
 Type:  New feature   | Status:  new
Component:  Core (Other)  |Version:  master
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 Broken links can exist in ways other than 404, such as 403 errors. The
 following patch modifies BrokenLinkEmailsMiddleware to send an email on
 all 4xx errors.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/052.6c8b832ede5fb037d3910a3e58d43792%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22170: Add initial migrations for contrib apps

[Django]

#22170: Add initial migrations for contrib apps
-+
 Reporter:  timo |Owner:
 Type:  New feature  |   Status:  new
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+

Comment (by claudep):

 I find the `auth` migration really hard to do right, if anyone feels like
 doing it, please go ahead. I think it could be done independently of other
 migrations. The difficulty lies in having two sets of migrations (one with
 custom user for tests and one "normal") and playing nicely with
 `runtests.py`, `migrate` and `flush`.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/062.de5387da31b45104acee064ae8658aa2%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22170: Add initial migrations for contrib apps

[Django]

#22170: Add initial migrations for contrib apps
-+
 Reporter:  timo |Owner:
 Type:  New feature  |   Status:  new
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+
Changes (by claudep):

 * needs_better_patch:  0 => 1
 * stage:  Ready for checkin => Accepted


Comment:

 Back to accepted:
  * Loïc suggested a workaround to the `initial.py` vs `0001_initial.py`
 naming issue in auth.
  * I must have forgotten to include the sessions migration
  * A more serious issue I discovered is about the `auth` and
 `MIGRATION_MODULES` hack in `runtests.py`:
if we include the `MIGRATION_MODULES` hack in `runtests.py` and don't
 include `django.contrib.auth` in tested labels, the creation of the test
 database fails because the `flush` command fails (`auth_customuser` table
 missing).

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/062.b70be1d0eb060acbb40afa84fbb1c9cf%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22573: ImportError: No module named header

[Django]

#22573: ImportError: No module named header
-+--
 Reporter:  Haikson  |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Uncategorized|  Version:  1.6
 Severity:  Release blocker  |   Resolution:  invalid
 Keywords:  1.6.4| Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by timo):

 * status:  new => closed
 * needs_better_patch:   => 0
 * resolution:   => invalid
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 I don't think this is an issue with Django. I guess you might have another
 module named `email` on your Python path that's taking precedence over the
 Python stdlib version.

 https://code.djangoproject.com/wiki/TicketClosingReasons/UseSupportChannels

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.850d4e60bd5b2cfe3117bf4ef902c9fd%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22572: @override_settings(ROOT_URLCONF) doesn't clear urlresolvers._urlconfs.

[Django]

#22572: @override_settings(ROOT_URLCONF) doesn't clear urlresolvers._urlconfs.
---+--
 Reporter:  loic84 |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Testing framework  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by anubhav9042):

 I think the issue being raised is valid and the PR opened is good to go.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.c1b1292a28c2e2031b304d927153ac03%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #22573: ImportError: No module named header

[Django]

#22573: ImportError: No module named header
-+
 Reporter:  Haikson  |  Owner:  nobody
 Type:  Uncategorized| Status:  new
Component:  Uncategorized|Version:  1.6
 Severity:  Release blocker  |   Keywords:  1.6.4
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+
 Traceback (most recent call last):
   File "./wsgi.py", line 13, in 
 from django.core.wsgi import get_wsgi_application
   File "/srv/env/vsevseti/lib/python2.7/site-
 packages/django/core/wsgi.py", line 1, in 
 from django.core.handlers.wsgi import WSGIHandler
   File "/srv/env/vsevseti/lib/python2.7/site-
 packages/django/core/handlers/wsgi.py", line 9, in 
 from django import http
   File "/srv/env/vsevseti/lib/python2.7/site-
 packages/django/http/__init__.py", line 4, in 
 from django.http.response import (HttpResponse, StreamingHttpResponse,
   File "/srv/env/vsevseti/lib/python2.7/site-
 packages/django/http/response.py", line 6, in 
 from email.header import Header
 ImportError: No module named header
 unable to load app 0 (mountpoint='') (callable not found or import error)
 *** no app loaded. going in full dynamic mode ***
 *** uWSGI is running in multiple interpreter mode ***
 spawned uWSGI master process (pid: 24205)
 spawned uWSGI worker 1 (pid: 24212, cores: 1)
 --- no python application found, check your startup logs for errors ---

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/050.67a764f52774b9a7c8d78836b88c3b9c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22572: @override_settings(ROOT_URLCONF) doesn't clear urlresolvers._urlconfs.

[Django]

#22572: @override_settings(ROOT_URLCONF) doesn't clear urlresolvers._urlconfs.
---+--
 Reporter:  loic84 |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Testing framework  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by loic84):

 * needs_docs:   => 0
 * has_patch:  0 => 1
 * needs_tests:   => 0
 * needs_better_patch:   => 0


Comment:

 PR https://github.com/django/django/pull/2631.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.b73b8fdc5778782c32abee94ba61afdd%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #22572: @override_settings(ROOT_URLCONF) doesn't clear urlresolvers._urlconfs.

[Django]

#22572: @override_settings(ROOT_URLCONF) doesn't clear urlresolvers._urlconfs.
---+
 Reporter:  loic84 |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Testing framework  |Version:  master
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 `BaseHandler.get_response()` sets `urlresolvers._urlconfs` through the
 `set_urlconf()` function; this normally happens for every request.

 The test client calls `get_response()`,  but since
 `@override_settings(ROOT_URLCONF)` doesn't clear it, further `reverse`
 outside of the test client may fail.

 This only affects single tests with multiple `override_settings` because
 `SimpleTestCase` clears the urlconf between tests.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/049.a5075243bf67eea0bced4853fe4fdb67%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #21987: Allow Media objects to have their own MEDIA_TYPES

[Django]

#21987: Allow Media objects to have their own MEDIA_TYPES
-+-
 Reporter:  Keryn Knight |Owner:  Osmose
   |   Status:  assigned
 Type:   |  Version:  master
  Cleanup/optimization   |   Resolution:
Component:  Forms| Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  1
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by hirokiky):

 @Osmose thanks for your reply. the after one sounds greater!  > throwing
 one when there's a name conflict in the MEDIA_TYPES list

 #22298 discussion looks hassle a little (´Д｀), the patch will probably
 have to wait for a while.
 But you've done a great job. im pretty sure.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/095.47b6c257b8179f87d6a83ba99ba06945%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22466: 'ManyToOneRel' object has no attribute 'rel'

[Django]

#22466: 'ManyToOneRel' object has no attribute 'rel'
-+-
 Reporter:  takis|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:
  (models, ORM)  |  1.7-beta-2
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by loic84):

 How does ordering by the reverse of a FK  even work considering there are
 potentially many result?

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.57bbd3c1bc60c4989e49887d96f296d4%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22510: Form fields cannot have names that are present as attributes on the form

[Django]

#22510: Form fields cannot have names that are present as attributes on the form
-+--
 Reporter:  gc@… |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Documentation|  Version:  1.7-beta-2
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by loic84):

 Allowing `MyForm().foo == MyForm['foo']` would require additional magic.
 Fields defined declaratively are stored in `Form.declared_fields`, those
 fields should be considered immutable, they are then cloned into
 `Form.fields` in `Form.__init__` where they can be freely modified by form
 instances. If we just stuck to python inheritance and didn't remove
 fields, we'd expose a big footgun where altering `self.fieldname` would
 alter the form globally. We could mitigate the problem by shadowing
 declared fields by their clone in `__init__`, but that's just additional
 magic, and it doesn't offer much benefit over `Form.fields`. All in all,
 I'm -0 on this option.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/071.2018bc8812f1d1367773764e116efd27%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22501: The testing client of LiveServerTestCase has the wrong server address

[Django]

#22501: The testing client of LiveServerTestCase has the wrong server address
---+--
 Reporter:  daonb  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Testing framework  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by daonb):

 * status:  closed => new
 * has_patch:  0 => 1
 * resolution:  invalid =>


Comment:

 Sorry for not being descriptive enough, let me try again.

 My app's view is accessing the RESTfull API of my project and is using the
 request object to find out the local address (I know it's not the right
 way to do thing, and I'm only doing it because we have two projects that
 interact and it's still not clear where the app will be).  Writing the
 tests we've discovered that even though we're using the
 LiveServerTestCase, the view gets the wrong address in the `request`
 object.

 https://github.com/daonb/django/tree/ticket_22501

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.d39f8413f1c15ab616750ae0d79b76ff%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.