Sorry, accidentally sent private response by mistake. Resending.
Neil Williams <codeh...@debian.org> writes:
> Downgrading to 1.8 in testing fixes the problem, so if this isn't the
> root cause, something else in 1.9 is producing a misleading traceback.
> There's no reference to add-to-builtins in the lava-server code that I
> can find.
django-compat 1.0.7 has:
try:
from django.template.base import add_to_builtins
except ImportError: # Django < 1.8
from django.template import add_to_builtins
So looks like Django 1.8 does have it, but it moved. Which perhaps
should have been a warning that maybe this was a private symbol not
intended for apps to use.
django-compat 1.0.8 has in the release notes:
add_to_builtins was removed for Django 1.9, still available for
Django < 1.9
The relevant code is now:
if django.VERSION < (1, 8):
from django.template import add_to_builtins
elif django.VERSION < (1, 9):
from django.template.base import add_to_builtins
else:
pass # Removed in 1.9. Use template settings instead
I don't know what version of django-compat you have, however I think it
must be < 1.0.8
>From your stack trace it would appear that the calling application -
django-hijack - doesn't actually use add_to_builtins, however it uses
the file from django-compat that tries to import the symbol anyway.
Looks like this should be fixed with django-compat 1.0.8
As far as I can tell, django-compat isn't packaged for Debian.
It looks like the latest release of django-hijack 2.0.0 requires
django-compat >= 1.0.8
--
Brian May <b...@debian.org>
