Updates of existing backports are not usually announced in this way but there is a note to consider, so I'm covering that here.
Independent of the update of the lava-server and lava-dispatcher backports to 2016.4, admins using jessie-backports do need to be aware of a issue which is still pending related to django and django-tables.
A backport of django-tables is pending, waiting for these two packages to also be accepted into jessie-backports: https://ftp-master.debian.org/new/django-haystack_2.4.1-1~bpo8%2B1.html https://ftp-master.debian.org/new/python-fudge_1.1.0-1~bpo8%2B1.html
These are required before django-tables can build inside jessie-backports and therefore before I can upload a build of django-tables for jessie-backports.
Irrespective of the version of LAVA being used, if django itself is installed from jessie-backports, the version of django-tables in jessie will cause a HTTP500. The fix is to either downgrade django back to the version in jessie or to pull in the version of python-django-tables2 from *testing*.: https://packages.debian.org/stretch/python-django-tables2. It is this upstream version which is to be backported to jessie-backports.
Once these last two dependencies clear the queue for backports, I'll make the backport of django-tables and then admins can have django and django-tables from jessie-backports which will work. i.e. the installed django needs to match up with the installed django-tables - either both from jessie or, once available, both from jessie-backports.
This isn't a problem in LAVA as such, it affects LAVA and I'll have the fix available just as soon as the queue clears within Debian.
Finally, LAVA is likely to move to using django from jessie-backports once this issue is fixed so that instances gain the security fixes in the django 1.8 release - at that point, LAVA will ensure that the updated django-tables is pulled in at the same time. LAVA has been running with django 1.8 (and django1.9) for developers for some time, testing with 1.8 will continue in the meantime.