--- Begin Message ---
Package: release.debian.org
User: release.debian.org@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: python-modules-team@lists.alioth.debian.org
Dear release team,
Please consider unblocking 1.10.6-1 for stretch:
* It is a bugfix release from 1.10.5-1. The release notes are here:
<https://docs.djangoproject.com/en/1.10/releases/1.10.6/>
* Upstream have a good reputation for being stable/sensible wrt release
processes.
The relevant debian/changelog entry is
python-django (1:1.10.6-1) unstable; urgency=medium
* New upstream bugfix release:
- Fixed ClearableFileInput’s “Clear” checkbox on model form fields where
the model field has a default (#27805).
- Fixed RequestDataTooBig and TooManyFieldsSent exceptions crashing rather
than generating a bad request response (#27820).
- Fixed a crash on Oracle and PostgreSQL when subtracting DurationField or
IntegerField from DateField (#27828).
- Fixed query expression date subtraction accuracy on PostgreSQL for
differences larger than a month (#27856).
- Fixed a GDALException raised by GDALClose on GDAL ≥ 2.0 (#27479).
debdiff is attached, most of which is updating the documentation/tests rather
than code itself.
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` lamby@debian.org / chris-lamb.co.uk
`-
diff -Nru python-django-1.10.5/debian/changelog python-django-1.10.6/debian/changelog
--- python-django-1.10.5/debian/changelog 2017-01-05 09:34:42.000000000 +0000
+++ python-django-1.10.6/debian/changelog 2017-03-01 20:27:22.000000000 +0000
@@ -1,3 +1,18 @@
+python-django (1:1.10.6-1) unstable; urgency=medium
+
+ * New upstream bugfix release:
+ - Fixed ClearableFileInputâ??s â??Clearâ?? checkbox on model form fields where
+ the model field has a default (#27805).
+ - Fixed RequestDataTooBig and TooManyFieldsSent exceptions crashing rather
+ than generating a bad request response (#27820).
+ - Fixed a crash on Oracle and PostgreSQL when subtracting DurationField or
+ IntegerField from DateField (#27828).
+ - Fixed query expression date subtraction accuracy on PostgreSQL for
+ differences larger than a month (#27856).
+ - Fixed a GDALException raised by GDALClose on GDAL â?¥ 2.0 (#27479).
+
+ -- Chris Lamb <lamby@debian.org> Wed, 01 Mar 2017 20:27:22 +0000
+
python-django (1:1.10.5-1) unstable; urgency=medium
* New upstream bugfix release.
diff -Nru python-django-1.10.5/debian/.git-dpm python-django-1.10.6/debian/.git-dpm
--- python-django-1.10.5/debian/.git-dpm 2017-01-05 09:34:42.000000000 +0000
+++ python-django-1.10.6/debian/.git-dpm 2017-03-01 20:27:22.000000000 +0000
@@ -1,11 +1,11 @@
# see git-dpm(1) from git-dpm package
-6df8d6595a73ce176293504812907794267ea833
-6df8d6595a73ce176293504812907794267ea833
-ff948890704131513a97bcb09beef9ce22aa01e9
-ff948890704131513a97bcb09beef9ce22aa01e9
-python-django_1.10.5.orig.tar.gz
-07b638e6039ef9b04bd59f0e94f000b3889dde91
-7734715
+9e1c5de966ec84bda893f71e4d24080bfb53134e
+9e1c5de966ec84bda893f71e4d24080bfb53134e
+6af4842fcd60f750ff0cca6d0265854bd0910160
+6af4842fcd60f750ff0cca6d0265854bd0910160
+python-django_1.10.6.orig.tar.gz
+fd39b2134bafbd5b4af4500a948158abf3961e2b
+7734864
debianTag="debian/%e%%%v"
patchedTag="debian/patches/%e%%%v"
upstreamTag="upstream/%e%%%u"
diff -Nru python-django-1.10.5/debian/patches/02_disable-sources-in-sphinxdoc.diff python-django-1.10.6/debian/patches/02_disable-sources-in-sphinxdoc.diff
--- python-django-1.10.5/debian/patches/02_disable-sources-in-sphinxdoc.diff 2017-01-05 09:34:42.000000000 +0000
+++ python-django-1.10.6/debian/patches/02_disable-sources-in-sphinxdoc.diff 2017-03-01 20:27:22.000000000 +0000
@@ -1,4 +1,4 @@
-From 15805219b8a4a50aaa4b47e953a42735ef9dfb59 Mon Sep 17 00:00:00 2001
+From 6b7a6fd2d8bd46eaee2f9d59269fab42178ea231 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rapha=C3=ABl=20Hertzog?= <hertzog@debian.org>
Date: Sun, 11 Oct 2015 11:43:19 +1100
Subject: Disable creation of _sources directory by Sphinx
diff -Nru python-django-1.10.5/debian/patches/06_use_debian_geoip_database_as_default.diff python-django-1.10.6/debian/patches/06_use_debian_geoip_database_as_default.diff
--- python-django-1.10.5/debian/patches/06_use_debian_geoip_database_as_default.diff 2017-01-05 09:34:42.000000000 +0000
+++ python-django-1.10.6/debian/patches/06_use_debian_geoip_database_as_default.diff 2017-03-01 20:27:22.000000000 +0000
@@ -1,4 +1,4 @@
-From 6df8d6595a73ce176293504812907794267ea833 Mon Sep 17 00:00:00 2001
+From 9e1c5de966ec84bda893f71e4d24080bfb53134e Mon Sep 17 00:00:00 2001
From: Tapio Rantala <tapio.rantala@iki.fi>
Date: Sun, 11 Oct 2015 11:43:20 +1100
Subject: Use Debian GeoIP database path as default
diff -Nru python-django-1.10.5/django/contrib/gis/gdal/prototypes/raster.py python-django-1.10.6/django/contrib/gis/gdal/prototypes/raster.py
--- python-django-1.10.5/django/contrib/gis/gdal/prototypes/raster.py 2017-01-04 18:35:47.000000000 +0000
+++ python-django-1.10.6/django/contrib/gis/gdal/prototypes/raster.py 2017-03-01 13:28:17.000000000 +0000
@@ -30,10 +30,7 @@
# Raster Data Source Routines
create_ds = voidptr_output(std_call('GDALCreate'), [c_void_p, c_char_p, c_int, c_int, c_int, c_int, c_void_p])
open_ds = voidptr_output(std_call('GDALOpen'), [c_char_p, c_int])
-if GDAL_VERSION >= (2, 0):
- close_ds = voidptr_output(std_call('GDALClose'), [c_void_p])
-else:
- close_ds = void_output(std_call('GDALClose'), [c_void_p])
+close_ds = void_output(std_call('GDALClose'), [c_void_p], errcheck=False)
flush_ds = int_output(std_call('GDALFlushCache'), [c_void_p])
copy_ds = voidptr_output(
std_call('GDALCreateCopy'),
diff -Nru python-django-1.10.5/django/core/handlers/exception.py python-django-1.10.6/django/core/handlers/exception.py
--- python-django-1.10.5/django/core/handlers/exception.py 2017-01-04 18:35:47.000000000 +0000
+++ python-django-1.10.6/django/core/handlers/exception.py 2017-03-01 13:28:15.000000000 +0000
@@ -7,7 +7,10 @@
from django.conf import settings
from django.core import signals
-from django.core.exceptions import PermissionDenied, SuspiciousOperation
+from django.core.exceptions import (
+ PermissionDenied, RequestDataTooBig, SuspiciousOperation,
+ TooManyFieldsSent,
+)
from django.http import Http404
from django.http.multipartparser import MultiPartParserError
from django.urls import get_resolver, get_urlconf
@@ -65,6 +68,11 @@
response = get_exception_response(request, get_resolver(get_urlconf()), 400, exc)
elif isinstance(exc, SuspiciousOperation):
+ if isinstance(exc, (RequestDataTooBig, TooManyFieldsSent)):
+ # POST data can't be accessed again, otherwise the original
+ # exception would be raised.
+ request._mark_post_parse_error()
+
# The request logger receives events for any problematic request
# The security logger receives events for all SuspiciousOperations
security_logger = logging.getLogger('django.security.%s' % exc.__class__.__name__)
diff -Nru python-django-1.10.5/django/db/backends/postgresql/operations.py python-django-1.10.6/django/db/backends/postgresql/operations.py
--- python-django-1.10.5/django/db/backends/postgresql/operations.py 2017-01-04 18:35:47.000000000 +0000
+++ python-django-1.10.6/django/db/backends/postgresql/operations.py 2017-03-01 13:28:17.000000000 +0000
@@ -252,7 +252,7 @@
if internal_type == 'DateField':
lhs_sql, lhs_params = lhs
rhs_sql, rhs_params = rhs
- return "age(%s, %s)" % (lhs_sql, rhs_sql), lhs_params + rhs_params
+ return "(interval '1 day' * (%s - %s))" % (lhs_sql, rhs_sql), lhs_params + rhs_params
return super(DatabaseOperations, self).subtract_temporals(internal_type, lhs, rhs)
def fulltext_search_sql(self, field_name):
diff -Nru python-django-1.10.5/django/db/models/expressions.py python-django-1.10.6/django/db/models/expressions.py
--- python-django-1.10.5/django/db/models/expressions.py 2017-01-04 18:35:47.000000000 +0000
+++ python-django-1.10.6/django/db/models/expressions.py 2017-03-01 13:28:15.000000000 +0000
@@ -382,7 +382,7 @@
return DurationExpression(self.lhs, self.connector, self.rhs).as_sql(compiler, connection)
if (lhs_output and rhs_output and self.connector == self.SUB and
lhs_output.get_internal_type() in {'DateField', 'DateTimeField', 'TimeField'} and
- lhs_output.get_internal_type() == lhs_output.get_internal_type()):
+ lhs_output.get_internal_type() == rhs_output.get_internal_type()):
return TemporalSubtraction(self.lhs, self.rhs).as_sql(compiler, connection)
expressions = []
expression_params = []
diff -Nru python-django-1.10.5/django/forms/widgets.py python-django-1.10.6/django/forms/widgets.py
--- python-django-1.10.5/django/forms/widgets.py 2017-01-04 18:35:47.000000000 +0000
+++ python-django-1.10.6/django/forms/widgets.py 2017-03-01 13:28:15.000000000 +0000
@@ -440,6 +440,12 @@
def use_required_attribute(self, initial):
return super(ClearableFileInput, self).use_required_attribute(initial) and not initial
+ def value_omitted_from_data(self, data, files, name):
+ return (
+ super(ClearableFileInput, self).value_omitted_from_data(data, files, name) and
+ self.clear_checkbox_name(name) not in data
+ )
+
class Textarea(Widget):
def __init__(self, attrs=None):
diff -Nru python-django-1.10.5/django/__init__.py python-django-1.10.6/django/__init__.py
--- python-django-1.10.5/django/__init__.py 2017-01-04 18:35:47.000000000 +0000
+++ python-django-1.10.6/django/__init__.py 2017-03-01 13:28:27.000000000 +0000
@@ -2,7 +2,7 @@
from django.utils.version import get_version
-VERSION = (1, 10, 5, 'final', 0)
+VERSION = (1, 10, 6, 'final', 0)
__version__ = get_version(VERSION)
diff -Nru python-django-1.10.5/Django.egg-info/PKG-INFO python-django-1.10.6/Django.egg-info/PKG-INFO
--- python-django-1.10.5/Django.egg-info/PKG-INFO 2017-01-04 19:18:01.000000000 +0000
+++ python-django-1.10.6/Django.egg-info/PKG-INFO 2017-03-01 13:30:41.000000000 +0000
@@ -1,6 +1,6 @@
Metadata-Version: 1.1
Name: Django
-Version: 1.10.5
+Version: 1.10.6
Summary: A high-level Python Web framework that encourages rapid development and clean, pragmatic design.
Home-page: http://www.djangoproject.com/
Author: Django Software Foundation
diff -Nru python-django-1.10.5/Django.egg-info/SOURCES.txt python-django-1.10.6/Django.egg-info/SOURCES.txt
--- python-django-1.10.5/Django.egg-info/SOURCES.txt 2017-01-04 19:18:01.000000000 +0000
+++ python-django-1.10.6/Django.egg-info/SOURCES.txt 2017-03-01 13:30:41.000000000 +0000
@@ -3447,6 +3447,7 @@
docs/releases/1.10.3.txt
docs/releases/1.10.4.txt
docs/releases/1.10.5.txt
+docs/releases/1.10.6.txt
docs/releases/1.10.txt
docs/releases/1.2.1.txt
docs/releases/1.2.2.txt
@@ -4339,6 +4340,7 @@
tests/gis_tests/relatedapp/tests.py
tests/gis_tests/relatedapp/fixtures/initial.json
tests/handlers/__init__.py
+tests/handlers/test_exception.py
tests/handlers/tests.py
tests/handlers/tests_custom_error_handlers.py
tests/handlers/urls.py
diff -Nru python-django-1.10.5/docs/howto/custom-management-commands.txt python-django-1.10.6/docs/howto/custom-management-commands.txt
--- python-django-1.10.5/docs/howto/custom-management-commands.txt 2017-01-04 18:35:47.000000000 +0000
+++ python-django-1.10.6/docs/howto/custom-management-commands.txt 2017-03-01 13:28:15.000000000 +0000
@@ -365,6 +365,12 @@
Rather than implementing :meth:`~BaseCommand.handle`, subclasses must implement
:meth:`~LabelCommand.handle_label`, which will be called once for each label.
+.. attribute:: LabelCommand.label
+
+ A string describing the arbitrary arguments passed to the command. The
+ string is used in the usage text and error messages of the command.
+ Defaults to ``'label'``.
+
.. method:: LabelCommand.handle_label(label, **options)
Perform the command's actions for ``label``, which will be the string as
diff -Nru python-django-1.10.5/docs/howto/deployment/wsgi/modwsgi.txt python-django-1.10.6/docs/howto/deployment/wsgi/modwsgi.txt
--- python-django-1.10.5/docs/howto/deployment/wsgi/modwsgi.txt 2016-12-28 20:07:28.000000000 +0000
+++ python-django-1.10.6/docs/howto/deployment/wsgi/modwsgi.txt 2017-02-20 23:09:28.000000000 +0000
@@ -34,6 +34,7 @@
.. code-block:: apache
WSGIScriptAlias / /path/to/mysite.com/mysite/wsgi.py
+ WSGIPythonHome /path/to/venv
WSGIPythonPath /path/to/mysite.com
<Directory /path/to/mysite.com/mysite>
@@ -49,6 +50,10 @@
any request below the given URL using the WSGI application defined in that
file.
+If you install your project's Python dependencies inside a `virtualenv`_, add
+the path to the virtualenv using ``WSGIPythonHome``. See the `mod_wsgi
+virtualenv guide`_ for more details.
+
The ``WSGIPythonPath`` line ensures that your project package is available for
import on the Python path; in other words, that ``import mysite`` works.
@@ -61,6 +66,9 @@
documentation</howto/deployment/wsgi/index>` for the default contents you
should put in this file, and what else you can add to it.
+.. _virtualenv: https://virtualenv.pypa.io/
+.. _mod_wsgi virtualenv guide: https://modwsgi.readthedocs.io/en/develop/user-guides/virtual-environments.html
+
.. warning::
If multiple Django sites are run in a single mod_wsgi process, all of them
@@ -90,26 +98,6 @@
See the :ref:`unicode-files` section of the Unicode reference guide for
details.
-Using a ``virtualenv``
-======================
-
-If you install your project's Python dependencies inside a `virtualenv`_,
-you'll need to add the path to this virtualenv's ``site-packages`` directory to
-your Python path as well. To do this, add an additional path to your
-``WSGIPythonPath`` directive, with multiple paths separated by a colon (``:``)
-if using a UNIX-like system, or a semicolon (``;``) if using Windows. If any
-part of a directory path contains a space character, the complete argument
-string to ``WSGIPythonPath`` must be quoted:
-
-.. code-block:: apache
-
- WSGIPythonPath /path/to/mysite.com:/path/to/your/venv/lib/python3.X/site-packages
-
-Make sure you give the correct path to your virtualenv, and replace
-``python3.X`` with the correct Python version (e.g. ``python3.4``).
-
-.. _virtualenv: https://virtualenv.pypa.io/
-
.. _daemon-mode:
Using ``mod_wsgi`` daemon mode
@@ -125,7 +113,7 @@
.. code-block:: apache
- WSGIDaemonProcess example.com python-path=/path/to/mysite.com:/path/to/venv/lib/python2.7/site-packages
+ WSGIDaemonProcess example.com python-home=/path/to/venv python-path=/path/to/mysite.com
WSGIProcessGroup example.com
If you want to serve your project in a subdirectory
diff -Nru python-django-1.10.5/docs/howto/error-reporting.txt python-django-1.10.6/docs/howto/error-reporting.txt
--- python-django-1.10.5/docs/howto/error-reporting.txt 2017-01-04 18:35:47.000000000 +0000
+++ python-django-1.10.6/docs/howto/error-reporting.txt 2017-03-01 13:28:15.000000000 +0000
@@ -125,10 +125,10 @@
.. warning::
Filtering sensitive data is a hard problem, and it's nearly impossible to
- guarantee that sensitive won't leak into an error report. Therefore, error
- reports should only be available to trusted team members and you should
- avoid transmitting error reports unencrypted over the Internet (such as
- through email).
+ guarantee that sensitive data won't leak into an error report. Therefore,
+ error reports should only be available to trusted team members and you
+ should avoid transmitting error reports unencrypted over the Internet
+ (such as through email).
Filtering sensitive information
-------------------------------
diff -Nru python-django-1.10.5/docs/intro/contributing.txt python-django-1.10.6/docs/intro/contributing.txt
--- python-django-1.10.5/docs/intro/contributing.txt 2016-12-28 20:07:28.000000000 +0000
+++ python-django-1.10.6/docs/intro/contributing.txt 2017-03-01 13:28:15.000000000 +0000
@@ -59,7 +59,7 @@
* Writing a test for your patch.
* Writing the code for your patch.
* Testing your patch.
-* Generating a patch file for your changes.
+* Submitting a pull request.
* Where to look for more information.
Once you're done with the tutorial, you can look through the rest of
@@ -308,6 +308,19 @@
:ref:`run the tests using a different database
<running-unit-tests-settings>`.
+Creating a branch for your patch
+================================
+
+Before making any changes, create a new branch for the ticket:
+
+.. code-block:: console
+
+ $ git checkout -b ticket_24788
+
+You can choose any name that you want for the branch, "ticket_24788" is an
+example. All changes made in this branch will be specific to the ticket and
+won't affect the main copy of the code that we cloned earlier.
+
Writing some tests for your ticket
==================================
@@ -497,31 +510,18 @@
an explanation of how to build a copy of the documentation locally, so you can
preview the HTML that will be generated.
-Generating a patch for your changes
-===================================
+Previewing your changes
+=======================
-Now it's time to generate a patch file that can be uploaded to Trac or applied
-to another copy of Django. To get a look at the content of your patch, run the
-following command:
+Now it's time to go through all the changes made in our patch. To display the
+differences between your current copy of Django (with your changes) and the
+revision that you initially checked out earlier in the tutorial:
.. code-block:: console
$ git diff
-This will display the differences between your current copy of Django (with
-your changes) and the revision that you initially checked out earlier in the
-tutorial.
-
-Once you're done looking at the patch, hit the ``q`` key to exit back to the
-command line. If the patch's content looked okay, you can run the following
-command to save the patch file to your current working directory:
-
-.. code-block:: console
-
- $ git diff > 24788.diff
-
-You should now have a file in the root Django directory called ``24788.diff``.
-This patch file contains all your changes and should look this:
+Use the arrow keys to move up and down.
.. code-block:: diff
@@ -603,23 +603,52 @@
# NullBooleanField is a bit of a special case because its presentation (widget)
# is different than its data. This is handled transparently, though.
-So what do I do next?
-=====================
+When you're done previewing the patch, hit the ``q`` key to return to the
+command line. If the patch's content looked okay, it's time to commit the
+changes.
-Congratulations, you've generated your very first Django patch! Now that you've
-got that under your belt, you can put those skills to good use by helping to
-improve Django's codebase. Generating patches and attaching them to Trac
-tickets is useful, however, since we are using git - adopting a more :doc:`git
-oriented workflow </internals/contributing/writing-code/working-with-git>` is
-recommended.
+Committing the changes in the patch
+===================================
+
+To commit the changes:
+
+.. code-block:: console
+
+ $ git commit -a
+
+This opens up a text editor to type the commit message. Follow the :ref:`commit
+message guidelines <committing-guidelines>` and write a message like:
+
+.. code-block:: text
-Since we never committed our changes locally, perform the following to get your
-git branch back to a good starting point:
+ Fixed #24788 -- Allowed Forms to specify a prefix at the class level.
+
+Pushing the commit and making a pull request
+============================================
+
+After committing the patch, send it to your fork on GitHub (substitute
+"ticket_24788" with the name of your branch if it's different):
.. code-block:: console
- $ git reset --hard HEAD
- $ git checkout master
+ $ git push origin ticket_24788
+
+You can create a pull request by visiting the `Django GitHub page
+<https://github.com/django/django/>`_. You'll see your branch under "Your
+recently pushed branches". Click "Compare & pull request" next to it.
+
+Please don't do it for this tutorial, but on the next page that displays a
+preview of the patch, you would click "Create pull request".
+
+Next steps
+==========
+
+Congratulations, you've learned how to make a pull request to Django! Details
+of more advanced techniques you may need are in
+:doc:`/internals/contributing/writing-code/working-with-git`.
+
+Now you can put those skills to good use by helping to improve Django's
+codebase.
More information for new contributors
-------------------------------------
@@ -665,13 +694,12 @@
__ https://code.djangoproject.com/query?status=new&status=reopened&needs_better_patch=1&easy=1&col=id&col=summary&col=status&col=owner&col=type&col=milestone&order=priority
__ https://code.djangoproject.com/query?status=new&status=reopened&needs_tests=1&easy=1&col=id&col=summary&col=status&col=owner&col=type&col=milestone&order=priority
-What's next?
-------------
+What's next after creating a pull request?
+------------------------------------------
After a ticket has a patch, it needs to be reviewed by a second set of eyes.
-After uploading a patch or submitting a pull request, be sure to update the
-ticket metadata by setting the flags on the ticket to say "has patch",
-"doesn't need tests", etc, so others can find it for review. Contributing
-doesn't necessarily always mean writing a patch from scratch. Reviewing
-existing patches is also a very helpful contribution. See
-:doc:`/internals/contributing/triaging-tickets` for details.
+After submitting a pull request, update the ticket metadata by setting the
+flags on the ticket to say "has patch", "doesn't need tests", etc, so others
+can find it for review. Contributing doesn't necessarily always mean writing a
+patch from scratch. Reviewing existing patches is also a very helpful
+contribution. See :doc:`/internals/contributing/triaging-tickets` for details.
diff -Nru python-django-1.10.5/docs/intro/install.txt python-django-1.10.6/docs/intro/install.txt
--- python-django-1.10.5/docs/intro/install.txt 2016-12-28 20:07:28.000000000 +0000
+++ python-django-1.10.6/docs/intro/install.txt 2017-01-23 16:46:17.000000000 +0000
@@ -53,13 +53,12 @@
You've got three easy options to install Django:
-* Install a version of Django :doc:`provided by your operating system
- distribution </misc/distributions>`. This is the quickest option for those
- who have operating systems that distribute Django.
-
* :ref:`Install an official release <installing-official-release>`. This
is the best approach for most users.
+* Install a version of Django :ref:`provided by your operating system
+ distribution <installing-distribution-package>`.
+
* :ref:`Install the latest development version
<installing-development-version>`. This option is for enthusiasts who want
the latest-and-greatest features and aren't afraid of running brand new code.
diff -Nru python-django-1.10.5/docs/ref/class-based-views/flattened-index.txt python-django-1.10.6/docs/ref/class-based-views/flattened-index.txt
--- python-django-1.10.5/docs/ref/class-based-views/flattened-index.txt 2016-12-28 20:07:28.000000000 +0000
+++ python-django-1.10.6/docs/ref/class-based-views/flattened-index.txt 2017-01-23 16:46:17.000000000 +0000
@@ -6,7 +6,12 @@
for class-based views. For each view, the effective attributes and methods from
the class tree are represented under that view. For the reference
documentation organized by the class which defines the behavior, see
-:doc:`Class-based views</ref/class-based-views/index>`
+:doc:`Class-based views</ref/class-based-views/index>`.
+
+.. seealso::
+
+ `Classy Class-Based Views <https://ccbv.co.uk/>`_ provides a nice interface
+ to navigate the class hierarchy of the built-in class-based views.
Simple generic views
====================
diff -Nru python-django-1.10.5/docs/ref/contrib/auth.txt python-django-1.10.6/docs/ref/contrib/auth.txt
--- python-django-1.10.5/docs/ref/contrib/auth.txt 2017-01-04 18:35:47.000000000 +0000
+++ python-django-1.10.6/docs/ref/contrib/auth.txt 2017-03-01 13:28:15.000000000 +0000
@@ -38,8 +38,7 @@
Although it wasn't a deliberate choice, Unicode characters have
always been accepted when using Python 3. Django 1.10 officially
added Unicode support in usernames, keeping the ASCII-only behavior
- on Python 2, with the option to customize the behavior using
- :attr:`.User.username_validator`.
+ on Python 2.
.. versionchanged:: 1.10
@@ -155,27 +154,6 @@
In older versions, this was a method. Backwards-compatibility
support for using it as a method will be removed in Django 2.0.
- .. attribute:: username_validator
-
- .. versionadded:: 1.10
-
- Points to a validator instance used to validate usernames. Defaults to
- :class:`validators.UnicodeUsernameValidator` on Python 3 and
- :class:`validators.ASCIIUsernameValidator` on Python 2.
-
- To change the default username validator, you can subclass the ``User``
- model and set this attribute to a different validator instance. For
- example, to use ASCII usernames on Python 3::
-
- from django.contrib.auth.models import User
- from django.contrib.auth.validators import ASCIIUsernameValidator
-
- class CustomUser(User):
- username_validator = ASCIIUsernameValidator()
-
- class Meta:
- proxy = True # If no new field is added.
-
Methods
-------
diff -Nru python-django-1.10.5/docs/ref/contrib/gis/install/index.txt python-django-1.10.6/docs/ref/contrib/gis/install/index.txt
--- python-django-1.10.5/docs/ref/contrib/gis/install/index.txt 2017-01-04 18:35:47.000000000 +0000
+++ python-django-1.10.6/docs/ref/contrib/gis/install/index.txt 2017-03-01 13:28:15.000000000 +0000
@@ -371,28 +371,10 @@
Proceed through the following sections sequentially in order to install
GeoDjango on Windows.
-.. note::
-
- These instructions assume that you are using 32-bit versions of
- all programs. While 64-bit versions of Python and PostgreSQL 9.x
- are available, 64-bit versions of spatial libraries, like
- GEOS and GDAL, are not yet provided by the :ref:`OSGeo4W` installer.
-
Python
~~~~~~
-First, download the latest `Python 2.7 installer`__ from the Python website.
-Next, run the installer and keep the defaults -- for example, keep
-'Install for all users' checked and the installation path set as
-``C:\Python27``.
-
-.. note::
-
- You may already have a version of Python installed in ``C:\python`` as ESRI
- products sometimes install a copy there. *You should still install a
- fresh version of Python 2.7.*
-
-__ https://python.org/download/
+:doc:`Install Python </howto/windows>`.
PostgreSQL
~~~~~~~~~~
diff -Nru python-django-1.10.5/docs/ref/contrib/sitemaps.txt python-django-1.10.6/docs/ref/contrib/sitemaps.txt
--- python-django-1.10.5/docs/ref/contrib/sitemaps.txt 2016-12-28 20:07:28.000000000 +0000
+++ python-django-1.10.6/docs/ref/contrib/sitemaps.txt 2017-03-01 13:28:15.000000000 +0000
@@ -456,7 +456,7 @@
<?xml version="1.0" encoding="UTF-8"?>
<urlset
xmlns="http://www.sitemaps.org/schemas/sitemap/0.9";
- xmlns:news="https://www.google.com/schemas/sitemap-news/0.9";>
+ xmlns:news="http://www.google.com/schemas/sitemap-news/0.9";>
{% spaceless %}
{% for url in urlset %}
<url>
diff -Nru python-django-1.10.5/docs/ref/forms/fields.txt python-django-1.10.6/docs/ref/forms/fields.txt
--- python-django-1.10.5/docs/ref/forms/fields.txt 2017-01-04 18:35:47.000000000 +0000
+++ python-django-1.10.6/docs/ref/forms/fields.txt 2017-03-01 13:28:15.000000000 +0000
@@ -92,6 +92,15 @@
For other ``Field`` classes, it might be ``None``. (This varies from field to
field.)
+Widgets of required form fields have the ``required`` HTML attribute. Set the
+:attr:`Form.use_required_attribute` attribute to ``False`` to disable it. The
+``required`` attribute isn't included on forms of formsets because the browser
+validation may not be correct when adding and deleting formsets.
+
+.. versionadded:: 1.10
+
+ Support for the ``required`` HTML attribute was added.
+
``label``
---------
diff -Nru python-django-1.10.5/docs/ref/forms/validation.txt python-django-1.10.6/docs/ref/forms/validation.txt
--- python-django-1.10.5/docs/ref/forms/validation.txt 2016-12-28 20:07:28.000000000 +0000
+++ python-django-1.10.6/docs/ref/forms/validation.txt 2017-03-01 13:28:15.000000000 +0000
@@ -69,8 +69,9 @@
formfield-specific piece of validation and, possibly,
cleaning/normalizing the data.
- This method should return the cleaned value obtained from ``cleaned_data``,
- regardless of whether it changed anything or not.
+ The return value of this method replaces the existing value in
+ ``cleaned_data``, so it must be the field's value from ``cleaned_data`` (even
+ if this method didn't change it) or a new cleaned value.
* The form subclass's ``clean()`` method can perform validation that requires
access to multiple form fields. This is where you might put in checks such as
@@ -315,8 +316,8 @@
if "fred@example.com" not in data:
raise forms.ValidationError("You have forgotten about Fred!")
- # Always return the cleaned data, whether you have changed it or
- # not.
+ # Always return a value to use as the new cleaned data, even if
+ # this method didn't change it.
return data
.. _validating-fields-with-clean:
diff -Nru python-django-1.10.5/docs/releases/1.10.6.txt python-django-1.10.6/docs/releases/1.10.6.txt
--- python-django-1.10.5/docs/releases/1.10.6.txt 1970-01-01 01:00:00.000000000 +0100
+++ python-django-1.10.6/docs/releases/1.10.6.txt 2017-03-01 13:28:17.000000000 +0000
@@ -0,0 +1,25 @@
+===========================
+Django 1.10.6 release notes
+===========================
+
+*March 1, 2017*
+
+Django 1.10.6 fixes several bugs in 1.10.5.
+
+Bugfixes
+========
+
+* Fixed ``ClearableFileInput``â??s "Clear" checkbox on model form fields where
+ the model field has a ``default`` (:ticket:`27805`).
+
+* Fixed ``RequestDataTooBig`` and ``TooManyFieldsSent`` exceptions crashing
+ rather than generating a bad request response (:ticket:`27820`).
+
+* Fixed a crash on Oracle and PostgreSQL when subtracting ``DurationField``
+ or ``IntegerField`` from ``DateField`` (:ticket:`27828`).
+
+* Fixed query expression date subtraction accuracy on PostgreSQL for
+ differences large an a month (:ticket:`27856`).
+
+* Fixed a ``GDALException`` raised by ``GDALClose`` on GDAL â?¥ 2.0
+ (:ticket:`27479`).
diff -Nru python-django-1.10.5/docs/releases/1.10.txt python-django-1.10.6/docs/releases/1.10.txt
--- python-django-1.10.5/docs/releases/1.10.txt 2016-12-28 20:07:28.000000000 +0000
+++ python-django-1.10.6/docs/releases/1.10.txt 2017-03-01 13:28:15.000000000 +0000
@@ -60,12 +60,11 @@
Python 3.
The username validator now explicitly accepts Unicode letters by
-default on Python 3 only. This default behavior can be overridden by changing
-the :attr:`~django.contrib.auth.models.User.username_validator` attribute of
-the ``User`` model, or to any proxy of that model, using either
+default on Python 3 only.
+
+Custom user models may use the new
:class:`~django.contrib.auth.validators.ASCIIUsernameValidator` or
-:class:`~django.contrib.auth.validators.UnicodeUsernameValidator`. Custom user
-models may also use those validators.
+:class:`~django.contrib.auth.validators.UnicodeUsernameValidator`.
Minor features
--------------
diff -Nru python-django-1.10.5/docs/releases/index.txt python-django-1.10.6/docs/releases/index.txt
--- python-django-1.10.5/docs/releases/index.txt 2017-01-04 18:35:47.000000000 +0000
+++ python-django-1.10.6/docs/releases/index.txt 2017-03-01 13:28:15.000000000 +0000
@@ -25,6 +25,7 @@
.. toctree::
:maxdepth: 1
+ 1.10.6
1.10.5
1.10.4
1.10.3
diff -Nru python-django-1.10.5/docs/topics/db/managers.txt python-django-1.10.6/docs/topics/db/managers.txt
--- python-django-1.10.5/docs/topics/db/managers.txt 2016-12-28 20:07:28.000000000 +0000
+++ python-django-1.10.6/docs/topics/db/managers.txt 2017-03-01 13:28:17.000000000 +0000
@@ -230,7 +230,7 @@
If you override the ``get_queryset()`` method and filter out any rows, Django
will return incorrect results. Don't do that. A manager that filters results
-in ``get_queryset()`` is not appropriate for use as a default manager.
+in ``get_queryset()`` is not appropriate for use as a base manager.
.. _calling-custom-queryset-methods-from-manager:
@@ -369,8 +369,10 @@
.. versionchanged:: 1.10
- In older versions, manager inheritance varied depending on the type of
- model inheritance (i.e. :ref:`abstract-base-classes`,
+ Some inheritance behaviors described above don't apply unless you set
+ ``manager_inheritance_from_future = True`` on the model's ``Meta`` class.
+ In older versions and if you don't set that attribute, manager inheritance
+ varies depending on the type of model inheritance (:ref:`abstract-base-classes`,
:ref:`multi-table-inheritance`, or :ref:`proxy-models`), especially
with regards to electing the default manager.
diff -Nru python-django-1.10.5/docs/topics/db/models.txt python-django-1.10.6/docs/topics/db/models.txt
--- python-django-1.10.5/docs/topics/db/models.txt 2017-01-04 18:35:47.000000000 +0000
+++ python-django-1.10.6/docs/topics/db/models.txt 2017-03-01 13:28:15.000000000 +0000
@@ -513,11 +513,9 @@
Unlike normal many-to-many fields, you *can't* use ``add()``, ``create()``,
or ``set()`` to create relationships::
- >>> # THIS WILL NOT WORK
+ >>> # The following statements will not work
>>> beatles.members.add(john)
- >>> # NEITHER WILL THIS
>>> beatles.members.create(name="George Harrison")
- >>> # AND NEITHER WILL THIS
>>> beatles.members.set([john, paul, ringo, george])
Why? You can't just create a relationship between a ``Person`` and a ``Group``
@@ -539,7 +537,7 @@
... invite_reason="You've been gone for a month and we miss you.")
>>> beatles.members.all()
<QuerySet [<Person: Ringo Starr>, <Person: Paul McCartney>, <Person: Ringo Starr>]>
- >>> # THIS WILL NOT WORK BECAUSE IT CANNOT TELL WHICH MEMBERSHIP TO REMOVE
+ >>> # This will not work because it cannot tell which membership to remove
>>> beatles.members.remove(ringo)
However, the :meth:`~django.db.models.fields.related.RelatedManager.clear`
diff -Nru python-django-1.10.5/docs/topics/db/queries.txt python-django-1.10.6/docs/topics/db/queries.txt
--- python-django-1.10.5/docs/topics/db/queries.txt 2017-01-04 18:35:47.000000000 +0000
+++ python-django-1.10.6/docs/topics/db/queries.txt 2017-03-01 13:28:15.000000000 +0000
@@ -1063,7 +1063,7 @@
reference fields local to the model being updated. If you attempt to introduce
a join with an ``F()`` object, a ``FieldError`` will be raised::
- # THIS WILL RAISE A FieldError
+ # This will raise a FieldError
>>> Entry.objects.update(headline=F('blog__name'))
.. _topics-db-queries-related:
diff -Nru python-django-1.10.5/docs/topics/install.txt python-django-1.10.6/docs/topics/install.txt
--- python-django-1.10.5/docs/topics/install.txt 2016-12-28 20:07:28.000000000 +0000
+++ python-django-1.10.6/docs/topics/install.txt 2017-03-01 13:28:15.000000000 +0000
@@ -181,6 +181,8 @@
.. _virtualenvwrapper: https://virtualenvwrapper.readthedocs.io/en/latest/
.. _standalone pip installer: https://pip.pypa.io/en/latest/installing/#installing-with-get-pip-py
+.. _installing-distribution-package:
+
Installing a distribution-specific package
------------------------------------------
diff -Nru python-django-1.10.5/docs/topics/logging.txt python-django-1.10.6/docs/topics/logging.txt
--- python-django-1.10.5/docs/topics/logging.txt 2017-01-04 18:35:47.000000000 +0000
+++ python-django-1.10.6/docs/topics/logging.txt 2017-03-01 13:28:15.000000000 +0000
@@ -382,7 +382,7 @@
* Defines two handlers:
- * ``console``, a StreamHandler, which will print any ``DEBUG``
+ * ``console``, a StreamHandler, which will print any ``INFO``
(or higher) message to stderr. This handler uses the ``simple`` output
format.
diff -Nru python-django-1.10.5/docs/topics/migrations.txt python-django-1.10.6/docs/topics/migrations.txt
--- python-django-1.10.5/docs/topics/migrations.txt 2017-01-04 18:35:47.000000000 +0000
+++ python-django-1.10.6/docs/topics/migrations.txt 2017-03-01 13:28:15.000000000 +0000
@@ -584,8 +584,8 @@
possible depends on how closely intertwined your models are and if you have
any :class:`~django.db.migrations.operations.RunSQL`
or :class:`~django.db.migrations.operations.RunPython` operations (which can't
-be optimized through) - Django will then write it back out into a new set of
-migration files.
+be optimized through unless they are marked as ``elidable``) - Django will then
+write it back out into a new set of migration files.
These files are marked to say they replace the previously-squashed migrations,
so they can coexist with the old migration files, and Django will intelligently
diff -Nru python-django-1.10.5/docs/topics/pagination.txt python-django-1.10.6/docs/topics/pagination.txt
--- python-django-1.10.5/docs/topics/pagination.txt 2017-01-04 18:35:47.000000000 +0000
+++ python-django-1.10.6/docs/topics/pagination.txt 2017-03-01 13:28:15.000000000 +0000
@@ -161,14 +161,14 @@
------------------
``orphans``
- The minimum number of items allowed on the last page, defaults to zero.
Use this when you don't want to have a last page with very few items.
If the last page would normally have a number of items less than or equal
to ``orphans``, then those items will be added to the previous page (which
becomes the last page) instead of leaving the items on a page by
themselves. For example, with 23 items, ``per_page=10``, and
``orphans=3``, there will be two pages; the first page with 10 items and
- the second (and last) page with 13 items.
+ the second (and last) page with 13 items. ``orphans`` defaults to zero,
+ which means pages are never combined and the last page may have one item.
``allow_empty_first_page``
Whether or not the first page is allowed to be empty. If ``False`` and
diff -Nru python-django-1.10.5/docs/topics/testing/tools.txt python-django-1.10.6/docs/topics/testing/tools.txt
--- python-django-1.10.5/docs/topics/testing/tools.txt 2017-01-04 18:35:47.000000000 +0000
+++ python-django-1.10.6/docs/topics/testing/tools.txt 2017-03-01 13:28:15.000000000 +0000
@@ -1168,7 +1168,7 @@
``test_index_page_view``.
The ``multi_db`` flag also affects into which databases the
-attr:`TransactionTestCase.fixtures` are loaded. By default (when
+:attr:`TransactionTestCase.fixtures` are loaded. By default (when
``multi_db=False``), fixtures are only loaded into the ``default`` database.
If ``multi_db=True``, fixtures are loaded into all databases.
diff -Nru python-django-1.10.5/PKG-INFO python-django-1.10.6/PKG-INFO
--- python-django-1.10.5/PKG-INFO 2017-01-04 19:18:03.000000000 +0000
+++ python-django-1.10.6/PKG-INFO 2017-03-01 13:30:44.000000000 +0000
@@ -1,6 +1,6 @@
Metadata-Version: 1.1
Name: Django
-Version: 1.10.5
+Version: 1.10.6
Summary: A high-level Python Web framework that encourages rapid development and clean, pragmatic design.
Home-page: http://www.djangoproject.com/
Author: Django Software Foundation
diff -Nru python-django-1.10.5/setup.cfg python-django-1.10.6/setup.cfg
--- python-django-1.10.5/setup.cfg 2017-01-04 19:18:03.000000000 +0000
+++ python-django-1.10.6/setup.cfg 2017-03-01 13:30:44.000000000 +0000
@@ -25,5 +25,4 @@
[egg_info]
tag_build =
tag_date = 0
-tag_svn_revision = 0
diff -Nru python-django-1.10.5/tests/expressions/tests.py python-django-1.10.6/tests/expressions/tests.py
--- python-django-1.10.5/tests/expressions/tests.py 2017-01-04 18:35:47.000000000 +0000
+++ python-django-1.10.6/tests/expressions/tests.py 2017-03-01 13:28:17.000000000 +0000
@@ -15,7 +15,7 @@
When,
)
from django.db.models.functions import (
- Coalesce, Concat, Length, Lower, Substr, Upper,
+ Cast, Coalesce, Concat, Length, Lower, Substr, Upper,
)
from django.test import TestCase, skipIfDBFeature, skipUnlessDBFeature
from django.test.utils import Approximate
@@ -676,6 +676,7 @@
delta2 = datetime.timedelta(seconds=44)
delta3 = datetime.timedelta(hours=21, minutes=8)
delta4 = datetime.timedelta(days=10)
+ delta5 = datetime.timedelta(days=90)
# Test data is set so that deltas and delays will be
# strictly increasing.
@@ -739,6 +740,18 @@
cls.deltas.append(delta4)
cls.delays.append(e4.start - datetime.datetime.combine(e4.assigned, midnight))
cls.days_long.append(e4.completed - e4.assigned)
+
+ # e5: started a month after assignment, very long duration
+ delay = datetime.timedelta(30)
+ end = stime + delay + delta5
+ e5 = Experiment.objects.create(
+ name='e5', assigned=sday, start=stime + delay, end=end,
+ completed=end.date(), estimated_time=delta5,
+ )
+ cls.deltas.append(delta5)
+ cls.delays.append(e5.start - datetime.datetime.combine(e5.assigned, midnight))
+ cls.days_long.append(e5.completed - e5.assigned)
+
cls.expnames = [e.name for e in Experiment.objects.all()]
def test_multiple_query_compilation(self):
@@ -862,7 +875,10 @@
)
at_least_5_days = {e.name for e in queryset.filter(completion_duration__gte=datetime.timedelta(days=5))}
- self.assertEqual(at_least_5_days, {'e3', 'e4'})
+ self.assertEqual(at_least_5_days, {'e3', 'e4', 'e5'})
+
+ at_least_120_days = {e.name for e in queryset.filter(completion_duration__gte=datetime.timedelta(days=120))}
+ self.assertEqual(at_least_120_days, {'e5'})
less_than_5_days = {e.name for e in queryset.filter(completion_duration__lt=datetime.timedelta(days=5))}
expected = {'e0', 'e2'}
@@ -906,7 +922,16 @@
over_estimate = Experiment.objects.exclude(name='e1').filter(
completed__gt=self.stime + F('estimated_time'),
).order_by('name')
- self.assertQuerysetEqual(over_estimate, ['e3', 'e4'], lambda e: e.name)
+ self.assertQuerysetEqual(over_estimate, ['e3', 'e4', 'e5'], lambda e: e.name)
+
+ def test_date_minus_duration(self):
+ value = (
+ Cast(Value(datetime.timedelta(days=4)), models.DurationField())
+ if connection.vendor == 'oracle'
+ else Value(datetime.timedelta(days=4), output_field=models.DurationField())
+ )
+ more_than_4_days = Experiment.objects.filter(assigned__lt=F('completed') - value)
+ self.assertQuerysetEqual(more_than_4_days, ['e3', 'e4', 'e5'], lambda e: e.name)
class ValueTests(TestCase):
diff -Nru python-django-1.10.5/tests/forms_tests/widget_tests/test_clearablefileinput.py python-django-1.10.6/tests/forms_tests/widget_tests/test_clearablefileinput.py
--- python-django-1.10.5/tests/forms_tests/widget_tests/test_clearablefileinput.py 2016-12-28 20:07:28.000000000 +0000
+++ python-django-1.10.6/tests/forms_tests/widget_tests/test_clearablefileinput.py 2017-03-01 13:28:15.000000000 +0000
@@ -149,3 +149,9 @@
# user to keep the existing, initial value.
self.assertIs(self.widget.use_required_attribute(None), True)
self.assertIs(self.widget.use_required_attribute('resume.txt'), False)
+
+ def test_value_omitted_from_data(self):
+ widget = ClearableFileInput()
+ self.assertIs(widget.value_omitted_from_data({}, {}, 'field'), True)
+ self.assertIs(widget.value_omitted_from_data({}, {'field': 'x'}, 'field'), False)
+ self.assertIs(widget.value_omitted_from_data({'field-clear': 'y'}, {}, 'field'), False)
diff -Nru python-django-1.10.5/tests/gis_tests/test_geoip.py python-django-1.10.6/tests/gis_tests/test_geoip.py
--- python-django-1.10.5/tests/gis_tests/test_geoip.py 2016-12-28 20:07:28.000000000 +0000
+++ python-django-1.10.6/tests/gis_tests/test_geoip.py 2017-03-01 13:28:15.000000000 +0000
@@ -142,7 +142,7 @@
def test05_unicode_response(self):
"Testing that GeoIP strings are properly encoded, see #16553."
g = GeoIP()
- fqdn = "hs-duesseldorf.de"
+ fqdn = "messe-duesseldorf.com"
if self._is_dns_available(fqdn):
d = g.city(fqdn)
self.assertEqual('Düsseldorf', d['city'])
diff -Nru python-django-1.10.5/tests/handlers/test_exception.py python-django-1.10.6/tests/handlers/test_exception.py
--- python-django-1.10.5/tests/handlers/test_exception.py 1970-01-01 01:00:00.000000000 +0100
+++ python-django-1.10.6/tests/handlers/test_exception.py 2017-03-01 13:28:15.000000000 +0000
@@ -0,0 +1,29 @@
+from django.core.handlers.wsgi import WSGIHandler
+from django.test import SimpleTestCase, override_settings
+from django.test.client import FakePayload
+
+
+@override_settings(ROOT_URLCONF='handlers.urls')
+class ExceptionHandlerTests(SimpleTestCase):
+
+ def get_suspicious_environ(self):
+ payload = FakePayload('a=1&a=2;a=3\r\n')
+ return {
+ 'REQUEST_METHOD': 'POST',
+ 'CONTENT_TYPE': 'application/x-www-form-urlencoded',
+ 'CONTENT_LENGTH': len(payload),
+ 'wsgi.input': payload,
+ 'SERVER_NAME': 'test',
+ 'SERVER_PORT': '8000',
+ 'PATH_INFO': '/malformed_post/',
+ }
+
+ @override_settings(DATA_UPLOAD_MAX_MEMORY_SIZE=12)
+ def test_data_upload_max_memory_size_exceeded(self):
+ response = WSGIHandler()(self.get_suspicious_environ(), lambda *a, **k: None)
+ self.assertEqual(response.status_code, 400)
+
+ @override_settings(DATA_UPLOAD_MAX_NUMBER_FIELDS=2)
+ def test_data_upload_max_number_fields_exceeded(self):
+ response = WSGIHandler()(self.get_suspicious_environ(), lambda *a, **k: None)
+ self.assertEqual(response.status_code, 400)
--- End Message ---